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Abstract 

Waterborne mines pose an asymmetric threat to naval forces. Their presence, whether actual or 
perceived, creates a low-cost yet very powerful deterrent that is notoriously dangerous and time- 
consuming to counter. In recent years, autonomous underwater vehicles (AUV) have emerged 
as a viable technology for conducting underwater search, survey, and clearance operations 
in support of the mine countermeasures (MCM) mission. With continued advances in core 
technologies such as sensing, navigation, and communication, future AUV MCM operations are 
likely to involve many vehicles working together to enhance overall capability. Given the almost 
endless number of design and configuration possibilities for multiple-AUV MCM systems, it is 
important to understand the cost-benefit trade-offs associated with these systems. 

This thesis develops an analytical framework for evaluating advanced AUV MCM system 
concepts. The methodology is based on an existing approach for naval ship design. For the 
MCM application, distinct performance and effectiveness metrics are used to describe a series 
of AUV systems in terms of physical/performance characteristics and then to translate those 
characteristics into numeric values reflecting the mission-effectiveness of each system. The mis¬ 
sion effectiveness parameters are organized into a hierarchy and weighted, using Analytical 
Hierarchy Process (AHP) techniques, according to the warfighter’s preferences for a given op¬ 
erational scenario. Utility functions and modeling provide means of relating the effectiveness 
metrics to the system-level performance parameters. Implementation of this approach involves 
two computer-based models: a system model and an effectiveness model, which collectively per¬ 
form the tasks just described. The evaluation framework is demonstrated using two simple case 
studies involving notional AUV MCM systems. The thesis conclusion discusses applications 
and future development potential for the evaluation model. 
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Chapter 1 


Introduction 


1.1 Motivation 

1.1.1 The Role of AUV MCM Systems in Naval Operations 

Autonomous underwater vehicles (AUV) are recognized by the U.S. Navy as a vital technology 
for future battlespace preparation and tactical operations in support of a broad range of warfare 
missions [1]. Among these missions is mine countermeasures (MCM), which generally consists 
of two sub-missions: mine reconnaissance and mine clearance. The MCM “mission need” is 
difficult to bound since it is tied directly to the larger warfighting requirements of sea control 
and access. In the near-term, the Navy is focused on conducting rapid, in-stride reconnaissance 
operations in the littoral region to enable fast-paced expeditionary operations [2], [3]. Achieving 
this level of capability represents a significant leap from that of today’s MCM force. The 
true MCM mission need goes far beyond in-stride reconnaissance to include such challenging 
operational scenarios as covert surveillance, detailed bottom mapping, and mine clearance - all 
required to be done quickly, over large areas, and from deep water to the shoreline. AUV systems 
have the inherent characteristics to satisfy this MCM mission need. Increasingly capable and 
relatively inexpensive, these systems could offer the naval commander unprecedented leverage 
and flexibility in conducting rapid, yet thorough, underwater search and clearance missions 
with minimal risk to human life. 

Within the U.S. defense community, many underwater vehicle system development efforts 
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are presently underway, several of which are intended for the MCM mission. The Remote Mine¬ 
hunting System (RMS) is an unmanned system composed of a semi-submersible vehicle and a 
towed body collectively housing an array of sonars. It is to be back-fit onboard DDG 51 class 
destroyers, beg inning in 2004, to provide an “organic” mine reconnaissance capability to the 
fleet. While not truly an AUV, it represents an incremental step toward in-stride, unmanned 
MCM. Also by 2004, the Navy plans to introduce its first tactical unmanned undersea vehicle 
(UUV) 1 , the Long-term Mine Reconnaissance System (LMRS) — a submarine-hosted vehicle 
with the planned capability to conduct clandestine mine reconnaissance. The Office of Naval 
Research (ONR) is funding other underwater vehicle research and development efforts, includ¬ 
ing a small modified oceanographic AUV called SAHRV, or Semi-autonomous Hydrographic 
Reconnaissance Vehicle, for minehunting in very shallow water regions[6]. Even while these 
pioneering programs are being implemented during this decade, continuing advances in AUV 
technology areas coupled with expanding confidence in AUV performance should enable steady 
progress toward more unconventional unmanned MCM systems. In their 1997 report [5], the 
National Research Council Committee on Technology for Future Naval Forces predicted the 
availability of “highly autonomous UUVs that operate in cooperative engagements” and are 
“capable of sensing their environments and communicating with each other to optimize under¬ 
water missions” in the 2035 timeframe. Relative to today’s capability, or even the near-term 
capability goals, the advent of these “cooperative multiple-AUV systems” will lead to vastly 
superior MCM systems. 

1.1.2 Transition to Cooperative Multiple-AUV Operations 

Cooperative multiple-AUV systems will strive to enhance overall system effectiveness by leverag¬ 
ing the individual capabilities of vehicles comprising that system. These individual capabilities 
can be stated in terms of vehicle sub-components, e.g. sensors, navigation units, data storage 
and processing devices, communications gear, and payload items. Functionally linking these 
physically distributed sub-components is communication, the bedrock capability of a multiple- 
vehicle system. Without intra-system communication, the benefits of employing multiple assets 

'The U.S. Navy often uses the term UUV when referring to unmanned underwater vehicle systems. An AUV 
is a type of UUV. 
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are reduced to the trivial case of cloning vehicles to reduce mission time. With communication, 
however, multiple-platform paradigms offer opportunities far beyond the simple linear scaling of 
performance. Such opportunities include multiple-sensor data fusion, collaborative navigation 
and localization, comm uni cations relay, and optimal asset allocation. The presence of multi¬ 
ple vehicles within a system, taken together with the probable communication link between the 
system and a host (e.g. a ship, submarine, satellite, etc.), also impacts the guidance and control 
architecture and underlying algorithms required for the system to function properly. 

The challenges of implementing AUV MCM systems, cooperative multi-AUV systems aside, 
are both technological and operational in nature. Beside the physical issues - energy source and 
through-water communication being two of the most daunting - there are significant operational 
control and oversight concerns that must be addressed. Engineers, systems integrators, and 
operators will have to sort through and understand these issues in seeking proper balance 
between overall system effectiveness and the cost required to achieve it. 

1.2 Problem Statement 

In the last decade, underwater vehicle research has led to great advances in such technologies as 
sensing, navigation, guidance, control, and communication. To reap the full potential of these 
technologies, AUVs must be capable of working together in a cooperative manner, making the 
best use of their complementary capabilities. Such systems may be composed from a vast range 
of vehicle types and sizes, sensors, navigation suites, communication packages, etc., resulting in 
a nearly limitless set of alternative configurations. For this reason, the design and employment of 
a cost-effective multiple-AUV system requires an understanding of the system’s dynamics and, 
in particular, the relationships between system configuration and performance characteristics. 
Typical questions that may be posed by decision-makers are: 

1. What is the right combination of AUV assets to employ for a particular mission? Should 
we use many inexpensive vehicles, a few high-performance vehicles, or a combination of 
the two? 

2. What types of sensors and how many of each are required for a particular mission? What 
are the sizes of the vehicles that must carry these sensors? 
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3. What navigation requirements are imposed and what navigational opportunities are cre¬ 
ated by multiple vehicles? 

4. What are the communication requirements between the vehicles and/or the Navy host 
platform? 

These are important and difficult questions, and they must be answered. Ultimately, though, 
it is the overall system effectiveness - the degree to which the system serves its intended purpose 
- that must be assessed in order to make appropriate decisions and therefore resolve these issues. 

1.3 Objectives 

The overarching objective of this thesis is to develop an analytical framework for the evaluation 
of advanced search concepts for multiple-AUV MCM. 

The effort described herein contributes to a larger project, funded by ONR, that aims to 
identify and evaluate a range of multiple-AUV operational paradigms for MCM missions [8]. 
This project, referred to as the “ONR project”, is described briefly in Section 2.1. In the 
early stages of the ONR project, the author and other participants identified the need for two 
basic levels of the eventual framework that would be used to evaluate notional AUV systems. 
The upper level would provide an environment for rapidly exploring various multi-AUV system 
configurations and tactical approaches for a given MCM scenario. The lower level would predict 
system performance and behavior in each case, perhaps through high-fidelity simulation, and 
provide the results to the upper level. The thesis focuses on the development of, methodology 
behind, and application for the overall evaluation framework. 

The intended thesis “product” is a computer-based decision-making tool. At the outset of 
the work, two core applications were identified for use in guiding and determining the scope of 
the project. These applications are presented in the form of the following questions: 

1. What AUV MCM system, in terms of individual vehicle design(s) and/or multi-vehicle 
combinations, most affordably meets the mission need and requirements? 

2. What is the most effective system configuration and operating profile for an AUV system 
embarked on a particular mission? 
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The first question relates to design and acquisition, while the second has more to do with 
operational employment. Realistically, a decision-maker will never possess the knowledge re¬ 
quired to answer these questions definitively. He can only hope to obtain the “best” solution 
by exploring the cost-effectiveness of each alternative according to his decision-making criteria. 
In support of the overall thesis objective, the following enabling objectives were set: 

1. Identify performance parameters and measures of effectiveness for multi-vehicle MCM 
approaches. 

2. Identify and select advanced multi-AUV sensing and navigation schemes which have po¬ 
tential for minehunting application. 

3. Create a computer-based multiple-AUV performance assessment model. 

4. Develop a cost-effectiveness model that facilitates translation of system performance char¬ 
acteristics into effectiveness scores and cost values. 

5. Evaluate the cost-effectiveness of notional multiple-AUV systems. 

1.4 Outline 

The thesis is organized into five chapters and three appendices. Chapter 2 briefly discusses other 
research efforts related to the use of underwater vehicles for MCM. Chapter 3 is the heart of 
the thesis. It details the methodology behind and the development of the evaluation framework. 
In Chapter 4, two case demonstrations are presented to illustrate the evaluation approach. A 
summary of the thesis and a short discussion of applications and possible follow-on work are 
given by Chapter 5. The appendices contain printouts of the Evaluation Model developed in 
the thesis. 
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Chapter 2 


Related Research 


2.1 Overview 

During the course of this thesis, the author became aware of a several major MCM systems 
research efforts being conducted by members/associates of the MCM community. In general, 
these fall into two broad application categories: very shallow water and surf zone (VSW/SZ), 
shallow water and deeper (SW). ONR currently funds a large number of individual and group 
projects that contribute to these efforts. Some of the organizations undertaking or involved in 
these projects include: 

Coastal Systems Station (CSS), Dahlgren Division, Naval Surface Warfare 
Center (NSWC); Panama City, Florida 
Naval Undersea Warfare Center (NUWC); Newport, Rhode Island 
Massachusetts Institute of Technology (MIT) 

Jolias Hopkins University (JHU), Applied Physics Laboratory (APL) 

Applied Research Laboratory (ARL), University of Texas (UT) at Austin 

Brief descriptions of those research efforts most applicable to this thesis are provided in the 
following sections. To at least some degree, the author collaborated with members from each 
of these organizations during the course of the thesis. 
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2.2 MIT Ocean Engineering Department 


As previously stated, the thesis contributes to a joint MIT Sea Grant - Bluefin Robotics Cor¬ 
poration project, funded by ONR, titled Sensor and Operational Trade-offs for Multiple AUV 
MCM. The objective of the project is “to develop the tools necessary to create a simulation 
environment in which to conduct sensor and platform trade-off studies for MCM missions involv¬ 
ing multiple AUVs”. As proposed, the work will lead to an advanced multi-vehicle simulation 
capability using high-fidelity physics-based models. 

While working on this thesis, the author communicated regularly with other members of 
the ONR project team. The framework developed herein will be used to guide the continued 
multi-AUV simulation and modeling effort. 

In addition to the ONR project, several ongoing research efforts within the MIT Ocean 
Engineering Department are applicable to the AUV concepts and technologies motivating this 
thesis. The research, mostly Navy-funded, can be categorized under the fields of ocean acoustics 
and underwater vehicle navigation. 

Professor Henrik Schmidt, who is the Principal Investigator for the ONR project and the 
advisor for this thesis, is currently engaged in a project examining new sonar concepts for 
shallow-water MCM. The project, called GOATS 2 , involves expanding a previously developed 
multi-AUV concept known as Autonomous Oceanographic Sampling Network (AOSN) [10]. 
During GOATS experiments in 1998 and 2000, participants explored the use of multiple, mo¬ 
bile platforms for mono-, bi-, and multi-static sensing and 3-D mapping of bottom objects, 
including buried mines [9]. These experiments have revealed the potential benefits of us¬ 
ing multiple, distributed AUVs to cooperatively conduct MCM searches in the VSW region 
of the littoral. An expected by-product of this work is the capability to acoustically model 
advanced multi-AUV sensing concepts. Such models will hopefully predict system-level detec¬ 
tion/classification/identification probabilities of notional multi-sensor configurations, and would 
nicely complement the evaluation framework developed in this thesis. 

The ability to conduct clandestine MCM operations will require AUV systems to navigate 
with high accuracy, ideally without having to penetrate the surface at all. Professor John 

2 Generic Oceanographic Array Technology System 
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Leonard’s research is concentrated in the area of advanced navigation and mapping technologies 
for underwater vehicles. In recent years, a main thrust has been feature-based concurrent 
mapping and localization (CML), a technique which enables an AUV to build a map of an 
unknown environment while simultaneously using that map to navigate with bounded position 
error [11]. The feature-based CML approach relies on high-resolution sonar data from which 
compact features, such as mines, lobster-traps, rock outcroppings, and so forth can be extracted. 
These features are then used to build the map that the AUV can use to determine its position 
and navigate from over an extended period of hours or days. This research is sponsored by 
NUWC. 

2.3 MCM Future Systems Working Group 

JHU/APL, ARL:UT, and CSS Panama City constitute the core of the MCM Future Systems 
Working Group. MIT and several other organizations are designated as supporting members of 
this working group. Since January 1998, the group has developed an array of system concepts, 
identified/researched future technologies, established performance metrics, and conducted a 
significant amount of analysis, mostly geared toward underwater vehicle systems for the SW 
MCM problem. Models developed include a UUV endurance model and associated cost model, 
and a MATLAB-based model for MCM-related calculations for UUVs. These models have been 
used to assess the MCM efforts of multiple underwater vehicles, but they are not intended for 
cooperative multi-vehicle systems. The evaluation framework developed in this thesis leverages 
some of the research provided by the working group, and is intended to complement their efforts. 

2.4 Naval Warfare Centers 

CSS and NUWC are two Navy warfare centers possessing a great deal of capability for UUV 
research and engineering. Additionally, CSS is very involved in a broad range of MCM systems 
engineering and analysis, with programs for surface-, air-, and underwater-based MCM. At CSS, 
work is being done in support of both the VSW/SZ and SW problems. Most applicable to this 
thesis are high-level simulation/evaluation analyses being performed for UUVs in the VSW/SZ 
problem, and separately for comparing unmanned surface vehicles (USV) MCM system concepts 
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to UUV concepts. NUWC has, in the past, been aligned with the anti-submarine warfare 
community and had little opportunity to participate in MCM system R&D work. However, the 
introduction of LMRS and other potential submarine-based and/or undersea warfare UUVs has 
caused NUWC to become involved in MCM system development. NUWC is also tasked with 
drafting and managing the Navy’s UUV Master Plan — a visionary document establishing the 
broad missions and required capabilities for all Navy UUVs [1]. 
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Chapter 3 


Evaluation Framework 

The objective of this thesis is to develop a framework for the evaluation of advanced search 
concepts for multi-AUV MCM. Chapter 3 addresses the development and architecture of this 
framework. 


3.1 Approach 

In the general context of warfare systems, determining the “right” system for a particular mis¬ 
sion need is a complex and challenging endeavor. From the early design phase to operational 
implementation, the process of fielding a typical warfare system involves many parties, each 
of whom make decisions according to a different set of criteria. A designer tends to focus on 
specific, intrinsic system characteristics (e.g. size, speed, and efficiency) that allow optimization 
of the system from an engineering standpoint, while the end user is concerned about the extent 
to which the system satisfies their own set of preferences or objectives. Additional parties may 
also impose objectives or constraints of their own, such as cost or production schedule. Eval¬ 
uating the overall cost-effectiveness of a system is further complicated when the system’s role 
in a larger “system of systems” is considered. For warfare system design and implementation, 
these realities demand a decision-making framework which integrates the contributions and 
preferences of all parties and measures the system’s effectiveness at the highest practical level 
of the system of systems hierarchy. 

An integrated design decision-making approach is used to varying degrees within the U.S. 
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Navy for system design and acquisition. Navy program offices and their supporting warfare and 
analysis centers evaluate system alternatives through a process called Analysis of Alternatives 
(AOA), which formalizes the procedure for assessing and documenting trade-offs associated 
with major program decisions [12]. In the AOA process, the “value” of a particular system 
alternative is established using parameters called measures of effectiveness (MOE) and measures 
of performance (MOP). The manner in which these MOE and MOP are identified and evaluated 
to support decision-making, however, is not rigidly established and so their use varies widely. 
In recent years, naval ship design curriculums at both Naval Post-graduate School (NPS) and 
Massachusetts Institute of Technology (MIT) have adopted “total ship system engineering” 
approaches to naval ship design. These approaches generally employ mission-oriented MOE 
and system-oriented MOP, prioritized via a system hierarchy, to evaluate the cost-effectiveness 
of several ship or submarine design alternatives with respect to the mission requirements. 

As a first step toward defining a multi-AUV MCM system evaluation framework, it is useful 
to compare the circumstances surrounding the evaluation of a multi-AUV MCM system versus a 
naval ship. The basic objective for each is the same: to identify the most cost-effective solution 
as measured against the collective set of criteria established by all parties involved in the process. 
Additionally, in each case, the set of effectiveness criteria is derived from a warfare mission to 
which other systems or platforms are also making a contribution. There are several striking 
diff erences between the two cases, however. One is found by considering their physical layouts. 
The ship is a single unit, while the multi-AUV system is, of course, a collection of individual 
vehicles. Adding to this contrast, the vehicle composition of a multi-AUV system could vary, 
even within a given mission scenario 3 . Beyond the physical differences lie unique operational 
and system dynamics issues associated the “virtually connected” and artificially intelligent 
multi-AUV system. Based on these characteristics, a multi-AUV system could be considered, 
from an evaluation standpoint, analogous to the networked task force or battle group directly 
above the naval ship in the system hierarchy. Interestingly, the AUV system is itself part of 
that same task force (since its purpose is to conduct MCM operations on behalf of the other 
members of that force). A framework for evaluating multi-AUV systems must, therefore, be 

3 This statement presumes that future AUV systems will consist of re-configurable and operationally flexible 
platforms that facilitate low-cost ’’mixing and matching” of not only vehicle sub-systems, but vehicle types within 
the system as well. 
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structured to handle the determination of effectiveness on several system hierarchy levels. 

The evaluation framework proposed in this thesis is based primarily on an approach pre¬ 
sented by Hockberger [13] for naval ship design. Hockberger combines several well-known 
systems engineering practices and decision-making methods in a framework suitable for naval 
ship design, emphasizing the importance of determining the ship’s effectiveness in the context 
of its “supersystem”. The proposed framework also incorporates techniques used by Whit¬ 
comb [14]. Whitcomb’s approach, which is itself based partly on the work of Hockberger, uses 
multiple-criteria decision-making (MCDM) methods to integrate multiple customer and com¬ 
pany preferences into the product design optimization process. The multi-AUV MCM system 
evaluation framework presented here provides an environment in which various system con¬ 
cepts, as defined by a system designer, can be evaluated in terms of overall cost-effectiveness 
from the perspective of the warfighter. 

3.2 Framework Architecture and Components 

The evaluation framework consists of two main components: an effectiveness model and a system 
model. A third component — the cost model — is required to complete the framework. For this 
thesis, cost estimates for AUV MCM systems are obtained using an underwater vehicle cost 
model developed for the MCM Future Systems Study discussed in Section 2.3. The effectiveness 
and system models are analytical in nature, meaning they use mathematical relationships to 
describe the system. As with any modeling effort, maintaining a balance between robustness, 
validity, programming effort, and flexibility required careful planning and structuring of the 
model environment. In this case, the general approach was to make the higher levels of the 
model as generic as possible, and to increase detail and resolution with each progression into 
the lower levels. This was accomplished by developing separate model sub-components and 
linking them together to form the overall system model, thereby achieving robustness without 
losing flexibility. Figure 3-1 illustrates the relationship between the framework components as 
envisioned early in the development process. 
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Figure 3-1: Evaluation Framework Model Components 

3.2.1 Effectiveness Model Component 

The effectiveness model addresses the objectives of the warfighter. These objectives are based 
on the mission, and are completely external to the system employed to pursue them. At the 
same time, it is essential that the objectives selected to represent the mission are a “complete, 
consistent, and correct” set of objectives with respect to the system(s) being evaluated [13]. 
An appropriate set of objectives can be selected and organized using common problem-solving 
and decision-making techniques, such as Quality Function Deployment (QFD) [16] and the 
Analytical Hierarchy Process (AHP) [17]. AHP is also an excellent tool for generating the 
priorities, or relative weights, of the objectives at each level in the effectiveness model in order 
to capture which aspects of the mission are most important to the warfighter. Another key 
aspect of the effectiveness model is the use of MOE. MOE measure the extent to which a 
system achieves the warfighter’s objectives. They can be given in terms of real units (e.g. 
knots) or as a scaled or normalized numerical score (e.g. 0.75 on a scale of 0 to 1). MOE values 
are necessarily dependent on system characteristics through sometimes difficult-to-establish 
relationships (discussed later). When properly selected, organized, weighted, and informed, the 
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MOE set provides a concise structure for presenting the effectiveness of a system alternative. 


3.2.2 System Model Component 

The system model plays two complementary roles in the evaluation framework. First, it provides 
a design environment in which the “user” defines a multi-AUV system in terms of its basic sub¬ 
components (e.g. sensors, navigation packages) and their associated performance characteristics 
and then “balances” that system to satisfy certain design requirements and constraints. Like 
most engineering models, the system model employs mathematical relationships to describe 
the interaction between the system’s components and to ensure compliance with the basic 
laws of physics. By working through the system design process and observing the effects on 
system performance/effectiveness, the designer gains at least a partial understanding of the 
system’s functional behavior. The second role of the system model is to estimate the physical 
and performance characteristics of a multi-AUV system. These characteristics are presented as 
MOP 1 , which are then used as inputs to the effectiveness model. 

3.2.3 Integration of the Model Components 

The effectiveness and system models can be viewed as agents working on behalf of the key players 
involved in multi-AUV MCM system implementation. The effectiveness model represents the 
warfighter, whose objectives are tied to mission scenarios which demand some level of MCM 
effort. The system model represents the designer or engineer, whose task is to optimize the 
system within the bounds of some set of requirements and constraints. The role of the agents 
is to establish a link between the efforts of the designer and the objectives of the warfighter so 
that, in effect, the designer’s frame of reference for optimization of the system is expanded to be 
the warfighter’s objectives. By doing so, a conceptual multi-AUV MCM system configuration 
can be evaluated in terms of its ability to satisfy the mission requirements rather than specific 
performance requirements that mean little to the warfighter. 

Of course, other players may be involved in the process, and their interests must be repre¬ 
sented as well. Such interests may include manufacturing capabilities, technology limitations, 

'The distinction between MOE and MOP is critical to understanding the framework developed in this the¬ 
sis and, beyond that, for all applications that use these parameters. In short, MOE are tied to the mission 
(alternatively: the customer’s requirements) while MOP are properties of the system (or product). 
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and cost. Often, these interests are addressed through constraints imposed directly on the de¬ 
signer. Cost, however, generally warrants independent consideration for several reasons. First, 
cost is somewhat unique in that several parties may have a vested interest in it, depending 
on the type of cost considered and the context of the evaluation. Acquisition cost is usually 
linked to annual defense budget constraints, as mandated by Congress, while the impact of 
life cost (e.g. operations, support, maintenance) concerns decision-makers at many levels, from 
Congress who allocates the money, to the warfighter who must carefully manage their fiscal 
resources. Second, cost constraints are difficult to establish. Decision-makers would prefer to 
get the “most for their money” rather than draw the line at some arbitrary upper cost limit. 
Given these unique characteristics, cost is best treated as a separate parameter against which 
the mission-effectiveness of the system can be compared. 

The effectiveness model and system model are linked by defining either qualitative or quan¬ 
titative relationships between the MOP of the system model and the MOE of the effectiveness 
model. Since MOE require input from one or more MOP, an MOE is said to be a function 
of MOP. Techniques for establishing the MOE-MOP relationships include modeling/simulation 
and direct assessment [13], [14]. Modeling and simulation efforts require a significant initial 
time investment and can be restrictive. However, if implemented properly, they permit rapid 
evaluation of complex problems and may be used repeatedly for similar applications. Direct 
assessment involves a dialog between the evaluator and decision-maker. Based on the results 
of the evaluator/decision-maker interaction, the evaluator constructs a utility function which 
reflects the judgement, preference, and/or experience of the decision-maker. Since each tech¬ 
nique has certain strengths and weaknesses, many evaluations use both techniques either for 
separate aspects or to augment one another. 

3-3 The Overall Evaluation Process 

Whether for design- or employment-related decisions, a formal evaluation process is needed 
to properly and consistently assess multi-AUV system(s) cost-effectiveness. This process in¬ 
volves three basic phases: problem, definition , generation of solution alternatives , and model¬ 
ing/evaluation of alternatives. The problem definition phase is associated with the effectiveness 
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Figure 3-2: Evaluation Process Flowchart 

model. During this phase, the overall mission is defined and the appropriate MOE hierarchy 
established. Next, operational scenario(s) are defined which characterize the environment and 
mine threat. Based on the mission and the operational scenario(s), MOE weights must be deter¬ 
mined. These weights should reflect the warfighter’s opinions regarding the relative importance 
of each MOE. (A method for determining these weights is discussed in Section 3.4.4) 

Once the mission aspects are addressed and the effectiveness model is set up, the assessor 
develops alternative solutions to be evaluated, along with corresponding MOP. If not already 
known, the MOE-MOP relationships must be derived. This is considered the beginning of 
the modeling and evaluation phase. Next, each system concept is designed/modeled in order to 
arrive at MOP and, therefore, MOE values. With a determination of system cost, the MOE and 
cost results are then available for evaluation and/or comparison to other system alternatives. 
Figure 3-2 shows the full sequence of events for the evaluation process 5 . 

The entire process must be completed for the setup of a new problem in order to develop 

5 This AUV system evaluation process was derived from the ” early stage ship design process” presented by 
Hockberger. 
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Figure 3-3: Streamlined Evaluation Process Flowchart 

the model(s) and establish all necessary relationships. Once this has been done, however, the 
basic model structure should accommodate any number of evaluation problems that fall under 
the overall mission. This includes changing the operational scenario, which would require 
modification to the MOE weights, but should not affect the MOE hierarchy. Depending on the 
way the lower-level system model was developed, there may be some restriction on the types 
of AUV systems that it can handle. If this is the case, the system model can be modified or 
replaced. The only requirement for the system model is that it provide the necessary MOP for 
determining the mission-specific MOE. The tailored process, for evaluating system alternatives 
after the initial problem setup, is illustrated in Figure 3-3. 

With the overall AUV system evaluation process defined, Sections 3.4 and 3.5 discuss the 
development of the effectiveness model and system model, respectively. 
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3.4 Effectiveness Model 


3.4.1 Overview 

Two main intentions guided the development of an effectiveness model. First, the model would 
facilitate the broadest possible range of notional underwater vehicle system designs, configu¬ 
rations, and operational employment scenarios. Second, the MOE selected would, so far as 
possible, be consistent with current or emerging U.S. Navy doctrine. To comply with these in¬ 
tentions, appropriate resources were obtained through Navy contacts and communication was 
established with other groups engaged in underwater vehicle MCM efforts (see Chapter 2). 

The following subsections present the AUV MCM System Effectiveness Model, developed as 
the first major component of the overall evaluation framework. The proper name “Effectiveness 
Model” is used to distinguish the particular model developed for the thesis from the more generic 
effectiveness model previously discussed. 

3.4.2 Mission and Operational Requirements 

Following the established evaluation process (Figure 3-2), the overall mission was identified as 
MCM. Assuming that the subject of the entire evaluation framework was AUV MCM systems, 
the system-specific operational requirements were defined as follows: 

1. Conduct MCM operations, including mine reconnaissance (detection, classification, iden¬ 
tification, and localization) and mine clearance (neutralization). 6 

2. Conduct operations with minimal reliance on support platforms. 

3. Conduct clandestine operations (as needed). 

4. Communicate with host platform or entity. 

6 In official U.S. Navy mine warfare terminology, the four levels of MCM effort are detection, classifica¬ 
tion, identification, and neutralization. Detection corresponds to discovering an object, classification determines 
whether the object is minelike or not, identification refers to positive designation as a mine, and neutralization 
removes the threat. Localization, which an important step for mapping and/or reacquisition of mine contacts, 
is sometimes included as a fifth level. 
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3.4.3 MOE Determination 

The Navy’s Program Executive Office for Mine Warfare (PEO(MIW)) defines MOE and MOP 
that address today’s mine warfare practices and systems. These metrics, largely geared toward 
surface- and air-based MCM systems, are designed to standardize the procedures for data 
collection and system evaluation throughout the fleet, yet are not intended to be all-inclusive 
or restrictive [15]. The existing MOE fall short of fully describing the potential capabilities of 
advanced underwater vehicle MCM systems. 

The Effectiveness Model MOE were established by considering the operational requirements 
for AUV MCM systems and comparing those requirements to the existing MOE to determine 
where modifications and additions were needed. PEO(MIW) Instruction 3370 [15] defines two 
force-level MOE: Time and Risk. The Time MOE refers to the time required to execute the 
specified mission, while the Risk MOE addresses the vulnerability of transiting platforms and 
MCM vehicles to the encountered minefield. Depending on the particular application, these 
MOE are determined from some combination of system/platform-level MOP. The Instruction 
defines thirty-two MOP. Examples include: sensor probabilities of detection, classification, 
and identification; probabilities of mine-to-target actuation and subsequent damage, and other 
platform characteristics such as transit speed to the area, search speed, time to turn, and 
endurance. A review of the MOE and their application to AUV MCM systems led to the 
following conclusions: 

• Near real-time communications may be desired with the AUV system. The vehicles 
abilities to relay information between themselves and to the surface (to a ship or satellite) 
will need to be measured. 

• Covertness is one of the primary benefits of an AUV system. This trait should be measured 
and incorporated into a measure of effectiveness. 

• AUVs, despite their name, will still require some level of logistics support, for deployment 
and recovery at least. This impact on the overall system effectiveness must be accounted 

for. 

• Human guidance/oversight of any system imposes demands on manning and other re- 
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sources, and should be considered during system evaluation. 

• Unmanned systems do not possess the same risk characteristics as manned systems. This 
aspect of the Risk MOE should be examined for possible modification. 

Based on the review, three new MOE were incorporated: Autonomy, Communication, and 
Covertness. A closer look at some of the contrasts between surface- or air-based MCM systems 
and underwater-based systems provides some added justification for these new MOE. MCM 
ships and aircraft today have essentially equivalent communication and covertness characteris¬ 
tics relative to each other. Their communication abilities are extensive, while their ability to 
conduct covert operations is almost non-existent. For AUVs, and especially for multiple-vehicle 
systems, covertness and communication abilities may vary significantly depending on the com¬ 
position and configuration of the system. This variability also applies to support/oversight 
requirements for underwater vehicle systems, whereas conventional systems have fairly uniform 
requirements. 

The existing Time MOE was adopted without modification, except to rename it Mission 
Time. The Risk MOE, however, was extensively modified and renamed Mission Accomplish¬ 
ment. The Mission Accomplishment MOE focuses on the end condition of the searched or 
cleared area rather than the vulnerability of transiting or MCM platforms. 

These five MOE - Mission Time, Mission Accomplishment, Autonomy, Communication, 
and Covertness - form the upper level of the MOE hierarchy, as shown in Figure 3-4. In 
anticipation of the need to link these MOE to the system MOP, the MOE were decomposed 
to form a second level of subordinate MOE. A brief description of each MOE and sub-MOE 
-follows. 

Mission Time 

The Mission Time MOE represents the time required for the AUV system to complete the 
assigned mission objectives. This is best expressed in terms of the effective area coverage rate 
(ACR), expressed in square nautical miles per hour. The effective ACR is defined as the ratio of 
the total search area to the total amount of time required to complete the mission objective(s), 
from AUV system deployment to recovery. This includes time spent in the search area plus 
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Figure 3-4: AUV MCM System Effectiveness Model Hierarchy 

transit time to/from the search area. An alternative sub-MOE is just the total mission time, 
given in hours. 

Mission Accomplishment 

The Mission Accomplishment MOE represents the estimated condition of the searched/cleared 
area after the mission is completed. This MOE reveals the extent to which any specified 
mission objectives were achieved or surpassed. The two basic classes of MCM missions are 
mine reconnaissance and mine clearance. The evaluation framework assumes that, for a given 
evaluation problem, only one of these missions will be in play. In other words, all systems 
being evaluated and compared will be operating under the same mission, either reconnaissance 
or clearance. Two of the three sub-MOE apply to the reconnaissance mission: search level 
and localization accuracy. For the recon mission, these two sub-MOE are weighted relative 
to each other, and the clearance level sub-MOE receives a zero weight. Search level refers 
to the cumulative probability of detecting, classifying, and correctly identifying mines within 
the specified search area. It is also commonly referred to as “percent search . Localization 
accuracy represents the distance error between the reported mine positions and the actual mine 
positions, or “contact position error”. For this model, the contact position error is taken as a 
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function of the system navigation error, the latter normally given as a percentage of distance 
traveled 7 . For a clearance mission, clearance level is given a weight of unity, and the other sub- 
MOE are zero. Clearance level refers to the cumulative probability of detecting, classifying, 
identifying (optional), and neutralizing mines within the specified search area, and is also known 
as “percent clearance”. For this thesis, the system model was not developed to describe mine 
clearance operations. 

Autonomy 

The Autonomy MOE represents the independence of the system from logistics support and/or 
oversight for guidance and tasking. Two subordinate MOE comprise the Autonomy MOE: 
Lift Support and Host Support. Lift support measures the amount of cargo space required 
for deployment/recovery of the system, given in terms of area (e.g. sqft). Host Support refers 
to the level of service and/or command and control support required during a mission. This 
requirement is specified in terms of discrete host responsibility alternatives (e.g. dedicated 
platform, remote command and control, none, etc.) 

Communication 

The Communication MOE represents the system’s capability to receive and/or transmit mission- 
related information from/to a host. The Communication MOE is broken down into two sub¬ 
ordinate MOE: Reporting Frequency and Data Type. Reporting frequency describes the fre¬ 
quency of transmissions (e.g. number of transmission occurrences per hour) from system to 
host or vice versa. Data type reflects the type of information being conveyed, particularly re¬ 
ferring to whether it is “low content” or “high content” data. Low content data would include 
CAD/CAC 8 , system position/status, contact positions, as well as command and control-related 
information from a host. High content data would be post-processed data intended for human 
interpretation, such as sonar imagery or “snippets”. 

7 If determined by post-analysis or simulation, localization error could be given as Distance Root Mean Squared 
(DRMS). 

8 CAD/CAC stands for computer-aided detection/classification and refers to the type of data being 
transmitted. 
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Covertness 


The Covertness MOE represents the extent to which the system’s presence and efforts are 
difficult to detect. The sub-MOE partition this MOE into three phases: deployment, mission, 
and recovery. Each sub-MOE represents the ability of the system to avoid detection during 
that particular phase. 

3.4.4 MOE Weights 

The relative weight assigned to each MOE and sub-MOE should reflect the preferences of the 
warfighter in relation to the mission and the specific scenario in play. While the warfighter may 
understand the mission very well and have a feeling of which system operational capabilities are 
more important than others, converting these subjective “values” into numeric weights is often 
difficult. The Analytical Hierarchy Process (AHP) provides a useful approach for attempting 
to establish the correct priorities among decision criteria. The method for establishing the 
Effectiveness Model MOE weights employs an AHP pairwise comparison technique, whereby 
the criteria are directly compared to each other (one pair at a time). These direct comparison 
results are then organized into matrix form, and the actual relative weights are determined from 
the matrix eigenvector corresponding to the largest eigenvalue [14]. The weighting technique is 
illustrated below for the five Effectiveness Model MOE. 

The first step is to order the MOE by relative importance for the given mission scenario. 
Recall that it is the warfighter whose preference structure should be extracted, either through 
surveys or other direct assessment means. For a typical MCM operation, the Mission Time 
and Mission Accomplishment will be regarded as the most critical parameters, forming the 
classic MCM trade-off between timely access to (or simply information about) a suspected 
problem area versus the acceptable risks in terms of loss of life, loss of capital assets, and/or 
loss of tactical advantage. The specific mission objectives for a given scenario will determine 
how Mission Time and Mission Accomplishment are weighted relative to each other. The 
Autonomy, Communication, and Covertness MOE will probably be weighted on a second tier of 
importance, but still must be compared to the first two. Whatever the case, the ordering of the 
MOE simplifies the process of assigning importance values during the pairwise comparison. For 
this example, the order is said to be Mission Time, Mission Accomplishment, Communication, 
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Autonomy, and Covertness. 

Next, each MOE is compared to the other MOE in turn. This can either be done for all com¬ 
binations of MOE pairs, or just the first round of comparisons, i.e. comparing one MOE to each 
of the others and then stopping. The AHP process emphasizes the former approach because 
it tends to more effectively remove bias from the exercise by providing multiple, overlapping 
opportunities to assign relative importance. After the eigenvalue problem is solved, a math¬ 
ematical check ensures that enough consistency exists in the pairwise weights. However, the 
full comparison approach can be time consuming. Beside the number of combinations required, 
the process may have to be repeated (with revised survey questions or clarification of some 
sort) in order to get the necessary consistency 9 . The second approach is faster, requiring just 
n-1 comparisons and resulting in a perfectly consistent matrix; however, the resulting weights 
may not reflect the warfighter’s preference structure as accurately as if all possible pairwise 
comparisons were made. Following the latter approach for this example, the MOE are assigned 
comparison values using Time as the reference MOE. The subscripts of the relative importance 
values, Rlij, should be read as “the relative importance of i over j”, where i and j correspond 
to the order of the MOE. Time is one, Accomplishment is two, and so forth. 


Time vs Accomplishment 
Time vs Communication 
Time vs Autonomy 
Time vs Covertness 


RIn = 1.5 
Rhs = 4 
RI14 — 6 

Rhs = 8 


The remaining RI values, representing the other six possible MOE pairs, are determined by 
taking ratios of the first four (if they are not obtained through direct comparison as described 
above). For example: 


Accomplishment vs Communication 


Rhz — 


RIn 

RI 12 


RI 23 = 2.667 


Setting up the eigenvalue problem, whose solution will yield the desired MOE weights, the 
Rlij values are placed in upper triangular section of a square matrix with columns and rows 

9 The number of possible pairwise comparisons is n(n— 1)/2, where n is the number of criteria. The consistency 
of the comparisons is measured by a parameter called the ’’inconsistency ratio , which should be less than a 
specified value [17]. Refer to Appendix C for detailed calculations. 
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representing the five MOE in the previously established order. Due to the symmetric properties 
of the matrix, the lower triangular elements are just the reciprocals of the corresponding upper 
half elements. 


( 1 1.5 4 6 8 ^ 


0.667 
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2.667 
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5.333 

0.25 

0.375 

1 
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0.25 
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1 

1.333 

^0.125 

0.188 

0.5 

0.75 
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Once the matrix is fully populated, the eigenvalue problem is solved (see Appendix C for 
details of the matrix solution). The normalized eigenvector associated with the maximum 
eigenvalue of the matrix contains the MOE weights of interest: 


MOEwt = 


^ 0 . 453 ^ 
0.302 
0.113 ■ 
0.075 
^0.057 j 


The AHP weighting method illustrated here can be used for establishing the relative weights 
on each level of the MOE hierarchy. In the Effectiveness Model, only the upper-level MOE were 
weighted by this method. The sub-MOE weights are entered directly, since there are no more 
than three to compare in each case. 


3.5 System Model 

3.5.1 Overview 

Recall the two main purposes of the system model within the evaluation framework: (1) to pro¬ 
vide an environment in which to design/configure a notional AUV system and (2) to determine 
the system MOP required as input to the Effectiveness Model. A system model could take many 
forms and serve many additional purposes, as long as it meets these basic requirements. For 
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this thesis, in keeping with the primary objective of evaluating “advanced search concepts for 
multiple-AUV MCM,” the system model was constructed according to the following philosophy. 

The absolute minimum requirements for the model would be to meet the two above-stated 
requirements of the evaluation framework and to incorporate, to some extent, the capability 
to handle multi-AUV system concepts. To aid in completing the model within the available 
timeframe, the operational requirements for the system would be limited to mine reconnaissance 
(searching and mapping), as opposed to mine clearance, and operational scenarios and tactics 
would be kept relatively simple. To reduce the burden on the user and facilitate rapid system 
definition, the model’s input requirements would be kept to a minimum by providing databases 
of vehicle sub-system components whose physical and performance characteristics are relatively 
well-understood. Finally, time permitting, the model would be scoped so as to allow evaluation 
of a broad range of AUV system concepts. At the low-capability end, this would include 
single-vehicle concepts, primarily for comparison reasons. At the high end, the model would 
handle “cooperative” multi-vehicle concepts, where the presence of multiple vehicles serves to 
significantly enhance the overall capabilities (and hopefully the cost-effectiveness) of the system. 

It is important to emphasize that, for this thesis, the System Model is not intended to 
accurately represent the physical or performance characteristics of the systems, but rather to 
provide consistent representation of the systems so that they can be evaluated in a relative 
sense. For real-world applications of the evaluation framework, consistency in the model will 
still be vital, and accuracy requirements for the system model will depend on the particular 
evaluation problem. 

3.5.2 System Model Components 

The AUV System Model, illustrated in Figure 3-5, consists of three modules: Input Mod¬ 
ule, Mission Planning Module, and AUV Design Module. Within the Input Module, the user 
specifies the scenario and tactical parameters for the mission, as well as the AUV system con¬ 
figuration and general characteristics. System configuration is entered in terms of the core 
mission-enabling sub-components for each type of vehicle. These sub-components, referred to 
as payload, include sensors, navigation units, and communications. The user also specifies the 
number of each type of vehicle, e.g. one Type A and five Type B. 
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Figure 3-5: AUV System Model 

The parameters required by the Input Module are listed in Table 3.1. The inputs are grouped 
into three categories: scenario, system definition, and tactical parameters. For an evaluation 
exercise, the scenario parameters are set and left constant while the system definition and 
tactical parameters are specified for each system alternative. Once the user has completed the 
initial data entry, certain information routes from the Input Module directly to the Effectiveness 
Model, while the remaining data is passed to the Mission Planning Module and AUV Design 
Module for further processing. 

The Mission Planning Module performs calculations pertaining to the MCM mission to 
reveal what is required of the system in order to meet the mission objectives. Specifically, 
the module determines the level of effort required by the system to achieve the user-specified 
MCM objectives. For example, if the user desires a percent search of 90% for a given area, the 
module will determine the number of tracks that the AUV system must run in order to achieve 
90%. The number of tracks is a critical parameter for determining the overall mission time. 
Mission time is the total time required for the system to complete the entire mission, and is 
also calculated in the Mission Planning Module. It includes the time required to run tracks, 
prosecute contacts, surface for navigation or communication (if required), and transit to and 
from the search area. The effective area coverage rate, which is equal to the total search area 
divided by the total mission time, is also provided by the module. Since the number of tracks 
is an integer, the predicted percent search that will be achieved will be slightly greater than 
the objective value, so the achieved percent search is given as an output of the module as well. 
The inputs and outputs for the Mission Planning Module are shown in Figure 3-6. 

It is worth pointing out that the outputs of the Mission Planning Module are actually MOE 
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Mission Objectives 

System-level Requirements 

Speed 

Percent search 

Number of vehicle types 

Search speed 

Transit distances 

Host-system comms method 

Transit speed 

Transit distances 

Reporting frequency 

Search Parameters 

Environment 

System navigation fix method 

Vehicle altitudes 

Bottom type category 

Contact position error threshold 

Number of runs/track 

Average water depth 

Reliability/redundancy level 

Sonar Performance Parameters 

Mine Threat 

Battery recharge method 

Characteristic search width 

Fraction of undetectable mines 

Delivery method for clandestine ops 

Characteristic probability of detect/class 

Assumed mine target strength 

Recovery method for clandestine ops 

Probability of identification 

Estimated number of mines 

Vehicle Requirements and Payload 

Navigation Performance 


Vehicle type/role 

Position error 


Number of vehicles (each type) 

Surfacing requirement (toggle) 

Maximum vehicle length 

Maximum vehicle diameter 

Maximum vehicle deadweight 

Sonar type(s) 

Navigation package 

Communication package 

Computer/processor 

Battery type 

Standard deviation of track keeping 


Table 3.1: Input Module Parameters 


Percent search desired 
Search area 
Transit distances 
Search speed 
Transit speed 
Sensor swaths 
Sensor detection probs 
Track deviation 


Mission Planning 
Module 


Mission time 

Percent search achieved 


Figure 3-6: Mission Planning Module Inputs and Outputs 
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that have been determined through modeling (as opposed to direct assessment), taking into 
account certain mission parameters. Admittedly, the inclusion of mission-oriented calculations 
in the system model is a deviation from the originally-stated approach. The reason for this 
deviation is to maintain consistency between the systems being evaluated by requiring some 
of the system parameters to be specified as objectives and to apply those objectives to all the 
systems being considered. This constrains the problem somewhat, forcing the values of certain 
parameters for each system to comply with the desired common objectives. As shown in Table 
3-6, the user-specified objectives for this model are percent search, search area, and transit 
distances. The System Model combines the given values with internally calculated time results 
to arrive at the total mission time. Mission time is then used as a reference for the endurance 
of the multi-AUV system, and therefore the endurance of each AUV within the system. The 
endurance of the system is fixed in this manner so that all systems being compared can be said 
to have just enough endurance to complete the mission (with some uniform margin built in, if 
desired). 

The AUV Design Module designs the individual AUVs based on the user-specified pay- 
load items and the results of the Mission Planning Module. This is done primarily to provide 
a reasonable estimate of vehicle sizes required to accommodate the payloads and meet the 
endurance requirement. The AUV Design Module was developed by modifying a parametric- 
based submarine design model*® currently used at MIT. The AUV version of the model performs 
three main engineering “balances”: volume required versus available, weight versus buoyancy, 
and speed versus power. For the volume balance, the module allows the user to adjust the 
vehicles dimensions and shape, essentially wrapping a shell around the payload components 
(sensor/navigation/communication/computer packages and battery), until the available vol¬ 
ume /displacement meets or exceeds that which is required. Vehicle weights are then estimated, 
and ballast requirements are calculated to achieve a desired buoyancy condition. For powering, 
the Module performs resistance calculations to determine the amount of energy (i.e. battery 
size/weight) required to meet the specified speed and endurance for the mission. The user 

10 The MIT SSN (attack submarine) Math Model is a Mathcad-based tool used for design courses in the Naval 
Construction and Engineering Program (13A). The original model, developed in 1995, was based on design 
parametrics developed by CAPT Harry Jackson, USN (Ret). The model has been updated by students and 
faculty over the last several years. The AUV version of the follows the general procedure of the SSN Model, but 
is greatly simplified and uses only a few of the same parametric relationships. 
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Payload weights 
Payload volumes 
Payload power rqmts 
Battery specs 
Endurance rqmt 
Search speed 
Transit speed 


AUV Design 
Module 


Length 

Diameter 

Weight 


Figure 3-7: AUV Design Module Inputs and Outputs 

iterates through the model to achieve an overall balance. Figure 3-7 summarizes the inputs and 
outputs for the AUV Design Module. 

3.5.3 System Model MOP 

For an AUV system modeled as described in the preceding paragraphs, the MOP should include 
all of the highest-level system physical and performance characteristics. As alluded to in the 
discussion of the Mission Planning Module, it is sometimes difficult to sort out the MOE and 
MOP, especially when the MOE are determined through modeling rather than utility functions. 
For this thesis, the rule-of-thumb for distinguishing between MOE and MOP has been to ask 
whether or not the parameter is purely system-dependent, or whether it depends on external, 
mission-related factors. In keeping with this, the MOP corresponding to each MOE were 
identified. Table 3.2 summarizes the MOP for each sub-MOE. 


3.6 The Integrated AUV MCM System Evaluation Model 

Bringing the System Model and Effectiveness Model together forms the Integrated AUV MCM 
System Evaluation Model. This framework permits the evaluation of notional AUV MCM sys¬ 
tems in the context of overall mission-effectiveness. Incorporating cost, the mission-effectiveness 
of the systems are weighed against the costs that are considered paramount, providing a firm 
basis for decision-making. Figure 3-8 illustrates the Integrated AUV MCM System Evaluation 
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MOE (Subordinates) 

MOP 

Effective Coverage Rate 

Search Speed (knots) 

Transit Speed (knots) 

Search Level 

Characteristic search width (yards) 


Characteristic probability of detection/classification (percent) 


Probability of identification (percent) 


Standard deviation of track keeping (yards) 

Localization Accuracy 

Navigation position error (% distance traveled) 

Lift Support 

System footprint (sqft) 

Host Support 

Platform requirement (levels) 

Reporting Frequency 

Reporting opportunities (levels) 

Data Type 

Data content (levels) 

Deployment Phase 

Platform type (levels) 

Mission Phase 

Platform type and standoff distance (levels) 

Recovery Phase 

Platform type (levels) 


Table 3.2: System Model MOP Corresponding to Effectiveness Model MOE 


Model. 

3.6.1 MOE-MOP Relationships 

The critical aspect of the Evaluation Model is the link between the MOE and MOP. Section 
3.2 discussed two general methods for determining MOE from MOP: modeling/simulation and 
direct assessment. For each MOE, the choice of translation method depends not only on the 
type of information that is available from the system model, but whether a non-subjective 
relationship between the system parameters and the MOE can be determined. If such a valid 
relationship can be established with a reasonable amount of effort, then modeling/simulation 
is the best choice. If not, a general (subjective) relationship, derived from direct assessment of 
~the warfighter's preferences, should be used. The Evaluation Model MOE-MOP relationships 
were forged according to these criteria. Table 3.3 summarizes the method of translation for 
each MOE-MOP set and lists, in the fourth column, the primary mission-related parameters 
and considerations that contribute to the relationships. In following subsections, the MOE- 
MOP relationships are presented. It is emphasized that the subjective relationships must be 
based on the warfighter’s preferences in order to be valid. For this thesis, no surveys or other 
means of assessment were conducted. For all subjective MOE-MOP relationships, the MOE 
scores corresponding to the MOP inputs were assigned by the author and are meant to be 
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Figure 3-8: Integrated AUV MCM System Evaluation Model 
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MOP 

MOE-MOP Transla¬ 
tion 

Mission Parameters 

Effective Coverage Rate 

Search Speed (knots) 

Modeling 

Search area 


Transit Speed (knots) 


Number of tracks 




Est. number of mines 

Search Level 

Characteristic search width (yards) 

Modeling 

Target strength 


Characteristic probability of detec¬ 
tion/classification (percent) 


Bottom type 


Probability of identification (per¬ 
cent) 


Sonar parameters 


Standard deviation of track keeping 
(yards) 


Water depth 

Localization Accuracy 

Navigation position error (% dis¬ 
tance traveled) 

Modeling 

Contact position error threshold 

Lift Support 

System footprint (sqft) 

Modeling 

Space restrictions; impact on 
other missions 

Host Support 

Platform requirement (levels) 

Subjective relationship 

Impact of host reqmt on other 
mission 

Reporting Frequency 

Reporting opportunities (levels) 

Subjective relationship 

Degree of need for host-system 
communication 

Data Type 

Data content (levels) 

Subjective relationship 

Degree of need for certain infor¬ 
mation types/formats 

Deployment Phase 

Platform type (levels) 

Subjective relationship 


Mission Phase 

Platform type and standoff distance 
(levels) 

Subjective relationship 

Desire to avoid detection 

Recovery Phase 

Platform type (levels) 

Subjective relationship 

Desire to avoid detection 


Table 3.3: MOE-MOP Translation Summary 


representative only. 


MOE-MOP Relationships for Mission Time 

Effective Area Coverage Rate is the sub-MOE used to describe the Mission Time MOE. It is 
equal to the search area divided by the total mission time. Total mission time is determined 
from the system’s speed and associated distance traveled during each segment of the operation. 
For this model, the time segments are: transit time, search time, navigation/communication 
excursion time, and prosecution time. Equation 3.1 applies. 


ACR e ff = 


Rsearcharea * Wsear char ea 


mission 


where, 

ACReff = Effective area coverage rate 


(3.1) 
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Lsearcharea ' Wsear chorea — Search area. 


Tmission = Total mission time 

The individual time calculations must be tailored to the type of operation being conducted, 
as well as the tactics employed. The details of these calculations for the Evaluation Model can 
be found in Appendix C. The source of Equation 3.1 is reference [15]. 

MOE-MOP Relationships for Mission Accomplishment 

For the minehunting problem, the Mission Accomplishment MOE receives its score from the 
Search Level and Localization Accuracy sub-MOE. The selected approach for predicting Search 
Level, or percent search, is based on an “approximation theory” developed by the Navy in 
the 1960s. This approach, outlined in PEO(MIW) Instruction 3370 [15], remains the standard 
method for estimating search and/or clearance levels for U.S. Navy MCM operations. It applies 
to uniform coverage over a set of parallel tracks. The governing relationships, as applied to 
the min ehunting problem for this thesis, are summarized as follows. The equation for percent 
search is: 


Psearch — (1 A 4 ) Pimm ' (1 e ) 


(3.2) 


where, 

Psearch = Percent search through identification 

/x = Fraction of undetectable mines 

Pimm = Probability of identifying a mine as a mine 

M = h —= Combined measure of area coverage level and detect/class success 
J = Number of runs per track 
A = Sensor characteristic search width 
D — Characteristic probability of detection/classification 
Dtrack — Distance between tracks 

OC A A 

Y = • f ln[l - B ■ (cnorm(u + £) - ( cnorm{u - £))]du 

o 

Y = Coefficient of MCM efficiency 
a = Standard deviation of track keeping error 
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cnorm(x ) = Value of the cumulative normal distribution function at x 

Localization Accuracy is determined in a much more straight-forward manner. A general 
assumption is made that the AUV MCM system will have some means of fixing its position 
periodically in order to navigate along the intended tracks. The System Model requires an 
entry for the maximum acceptable contact position error at any point during the search effort. 
Ignoring any error due to the sensor, and assuming further that the position error of the AUV 
grows linearly with time (i.e. as a percentage of distance traveled), the average contact position 
error over the course of the search should be approximately one half of the maximum position 
error: 

avg_pos_error = 0.5 * max _pos _error (3-3) 

MOE-MOP Relationships for Autonomy 

The sub-MOE for Autonomy are Lift Support and Host Support. Because Lift Support refers 
to the inconvenience or other costs associated with transporting the AUV system to/from the 
mission area, a reasonable metric is the system cargo area requirement, or footprint. The 
footprint is determined from Equation 3.4: 

numtype 

FPsys = fstowi-numvehi-FP ve h i (3-4) 

t=l 

where, 

FP S ys — Total AUV system footprint, or required cargo area 

numtype = Number of vehicle types in system 

fstowi = Stowage factor (fraction multiplier) for vehicle type i 

numvehi = Number of vehicles of the i th type 

FPyehi = Footprint of i th vehicle type 

Host Support is meant to reflect the level of service and/or command and control sup¬ 
port required during a mission. This sub-MOE, and in fact all of the remaining sub-MOE, 
are governed by completely subjective relationships as opposed to mathematical formulas. For 
example, Host Support is specified in terms of discrete host responsibility alternatives: dedi- 
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cated platform, remote command and control, and none required. Presumably, these levels of 
support have definite meaning to the warfighter, with “none required” being the ideal case and 
“dedicated platform” the worst. To figure out which case applies to the particular AUV system 
being evaluated, condition statements are used. The conditions are specific system characteris¬ 
tics that would cause a certain type of support to be required. In the Effectiveness Model, these 
conditional statements are written in terms of system parameters whose “values” are discrete 
designators, each of which represents a system characteristic. For all of the sub-MOE, these 
characteristics are specified as inputs, during system definition, so that the possible outcomes 
are set in advance. Table 3.4 lists the conditions that determine each level of the Host Support 
sub-MOE. 


Host Support Level 

Condition(s) 

Dedicated or in-theater support 

Reliability = “low” OR 

Communications method — “acoustic modem” OR 
Communications method = “RF line of sight” OR 
Battery recharge method = “host” 

Remote command and control 

Communications method = “RF via satellite” 

None required 

Otherwise 


Table 3.4: Conditions for Determining Host Support MOE Levels 


MOE-MOP Relationships for Communication 

The two sub-MOE for Communication, pertaining to how often communication occurs and 
how valuable the data is, are determined from system-level requirements specified in the Input 
Module. Tables 3.5 and 3.6 present the levels and conditions for Reporting Frequency and Data 
Type, respectively. 


Reporting Frequency Level 

Condition(s) 

None 

Reporting frequency = “not required” 

Periodic 

Communications method = “periodic” 

Continuous 

Otherwise 


Table 3.5: Conditions for Determining Reporting Frequency MOE Levels 
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Data Type Level 

Condition(s) 

None 

Communications method = “none required” 

Low-content data 

Communications method — “acoustic modem” 

High-content data 

Otherwise 


Table 3.6: Conditions for Determining Data Type MOE Levels 


MOE-MOP Relationships for Covertness 

For Covertness, the sub-MOE represent the likelihood of avoiding detection during any of three 
operational phases: Deployment Phase, Mission Phase, Recovery Phase. The ability of an AUV 
system to avoid detection will depend on many factors, including signatures (e.g. magnetic, 
acoustic, radar cross-section, etc.) and time spent in the area of concern. These factors apply 
not only to the AUV system, but also to its host platform, if applicable. To develop concise 
relationships for these sub-MOE, the problem was simplified by linking the level of covertness to 
the type of host platform required to support the AUV system during each of the three mission 
phases. In the case of the Mission Phase sub-MOE, the location of the platform (i.e. the 
proximity to the area of concern) is also factored in. This simplification assumes a significant 
relative difference between the signatures of the AUV system and the host platform. Three 
platform types are used in the relationships: surface, sub-surface, and air. For Mission Phase, 
the relationship is modified slightly so that it corresponds to the type of host platform required 
for the search. Tables 3.7 through 3.9 show the relationships. 


Delivery Phase Level 

Condition(s) 

Surface ship 

Delivery method = “surf” 

Aircraft 

Delivery method = “air” 

Submarine 

Delivery method = “sub” 

None required 

Delivery method = “not required” 


Table 3.7: Conditions for Determining Delivery Phase MOE Levels 


3.6.2 MOE Scoring and Interpretation 

Having established all MOE-MOP relationships for the Evaluation Model, the final task in 
the model’s development is to ensure the MOE are presented in a useful manner. Using the 
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Mission Phase Level 

Condition(s) 

Surface ship 

Otherwise (none of the below 
conditions) 

Submarine 

Delivery method = ”sub” 

Satellite/air link 

Host Support Level = NOT 
"none required" AND NOT 
"dedicated/in-theater support” 

None required 

Host Support Level = "none re¬ 
quired” 


Table 3.8: Conditions for Determining Mission Phase MOE Levels 


Recovery Phase Level 

Condition(s) 

Surface ship 

Delivery method — “surf" 

Aircraft 

Delivery method = “air” 

Submarine 

Delivery method = “sub” 

None required 

Delivery method = “not required” 


Table 3.9: Conditions for Determining Recovery Phase MOE Levels 

MOE results obtained above, comparison of even a small number of systems would be difficult 
because of the variation in the way the MOE ‘Values” are stated. Effective Coverage Rate, 
Search Level, Localization Accuracy, and Lift Support have real numeric values with associated 
units. The others are given as levels of capability or action that contribute to the mission. 
In many cases, a uniform scale of measure is desirable for comparison of sub-MOE between 
systems. Furthermore, such a scale is required in order to incorporate the MOE and sub-MOE 
weights. This, after all, is the main purpose of the effectiveness hierarchy (recall Figure 3-4). 
Still, for some comparisons, a mix of scaled and real values may be useful, as shown in the case 
demonstrations (Chapter 4). 

A simple means of scaling a parameter is to establish lower and upper bounds, assign them a 
score of 0 and 1, respectively, and then determine how the intermediate values of the parameter 
are scored on that scale. The result is a utility function which translates the original parameter 
value into a score between 0 and 1. If linear scaling is appropriate, the score for any intermediate 
value is determined by Equation 3.5: 


ScaledValued = (intermediate _value — low _value) / (high_value — low _value) (3.5) 
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For situations where desired output does not vary linearly with the input, a non-linear 
utility function is required. While not used in the Evaluation Model, one formal method for 
determining non-linear relationships is mentioned because of the possible applicability to fu¬ 
ture developments of the model. The technique follows the AHP pairwise comparison matrix 
procedure used to establish the MOE weights (Section 3.4.4), except that the eigenvector is 
scaled according to Equation 3.5 (rather than normalized). For this application, the row and 
column entries correspond to selected input parameter values instead of MOE, and it is those 
input values whose importance is compared in pairs to populate the matrix. The result is a 
piecewise-linear utility function that accounts for the macroscopic non-linearity of the relation¬ 
ship, but is linear between the values used for the comparison. Reference [14] provides details 
on this approach. 

Getting back to the Evaluation Model, the sub-MOE are scored as follows. For the sub-MOE 
that are given in terms of levels, scores of 0 and 1 are assigned to the least and most desirable 
levels, respectively. Because there are only a few, discrete intermediate levels to be scored, the 
scores can be directly assigned according to the warfighter’s preferences. For these sub-MOE, 
the scores are built into the MOE calculations because the named levels are more cumbersome 
for comparison purposes. For the remaining sub-MOE — those with real values initially — linear 
scaling is assumed, but not applied inside the Effectiveness Model. Instead, this is done in a 
separate spreadsheet, using Equation 3.5, only when the scores are to be multiplied by their 
associated sub-MOE weights (see end of Appendix C). 

To incorporate the MOE weights, the appropriately scaled sub-MOE are multiplied by their 
individual weights. The weighted scores under each MOE are then summed, and the five MOE 
weighted sums are added to obtain the overall MOE (OMOE). This single score now represents 
the entire AUV system on a scale of 0 to 1. The OMOE scores for a large number of systems 
can be plotted against an independent parameter, such as cost, to guide the evaluator(s) toward 
a decision as to which system or systems exhibit the best cost-effectiveness mix. 
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3.6.3 Implementation and Use 

The Evaluation Model is implemented in a series of worksheets (i.e. files) residing in two 
computer software programs: Mathcad 11 and Excel 12 . The files are linked together using com¬ 
patibility features of the two programs. Nearly all of the analytical calculations are performed 
by Mathcad, with Excel being used mostly for databasing, user entry, and graphical display 
of results. Mathcad was selected over other computing programs/languages, such as Matlab 
and Fortran, as much for its abilities as for its “what you see is what you get” presentation 
attributes. Equations, text, and graphics entered in the worksheet appear very much like you 
would see them on a blackboard or in a textbook. The highly visual nature of the model is 
intended to facilitate interpretation and understanding of the model’s underlying methodology 
so that future developments and extensions of the evaluation approach are not hindered by 
hard-to-follow programming codes. Appendix A contains a summary of the programmatic de¬ 
tails of the Evaluation Model, including a “wiring diagram” which illustrates how the various 
files are connected. Appendices B and C contain the System Model and Effectiveness Model, 
respectively. Appendix D contains AUV sub-system databases for the System Model. 

Having defined and presented the major components and relationships of the Evaluation 
Model, a more practical aspect of the model is now addressed: its use. In Section 3.3, the 
evaluation process was described (reference Figures 3-2 and 3-3). Figure 3-8 in Section 3.6 
summarizes the Evaluation Model, showing the connection between the System and Effective¬ 
ness Models. Merging the evaluation process and model architecture diagrams, Figure 3-9 
illustrates the evaluation process in the context of the modeling environment. Guided by this 
process, a typical AUV MCM system evaluation problem involves defining a series of system 
concepts, modeling each system to obtain MOE and cost results, and comparing the outcomes 
to reach a conclusion or decision. Chapter 4 further discusses the use of the Evaluation Model 
and the application of the evaluation framework as a whole. 


11 Mathcad 2000 Professional, by Mathsoft, Inc. 

12 Microsoft Excel 97, by Microsoft Corporation. 
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Figure 3-9: AUV MCM System Evaluation Flowchart 
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Chapter 4 


Case Demonstrations 


The primary purpose of the case demonstrations is to show, through simple examples, the 
basic features of the Evaluation Model and the manner in which results are obtained. The 
secondary purpose is to demonstrate the use of the model for two particular types of evaluation 
problems. In observing and discussing the results, the emphasis is placed on the nature of 
the outputs (rather than the actual values) and how they can assist the evaluator in reaching 
the sought-after decision and/or conclusions. It is important to note that, for both cases, the 
results themselves are based on non-validated technical information within the System Model 
and borrowed cost model, and so should be thought of as representative only. 

4.1 Case One 

4.1.1 Case One Definition 

The first case compares two AUV MCM system concepts that have very similar system-level 
requirements and sub-system components (i.e. sensor types, navigation packages, etc.), but 
are composed and configured quite differently. Presumably, the evaluator or decision maker 
is interested in identifying the key differences between each system, in terms of mission effec¬ 
tiveness, and then weighing those differences against the cost(s) of each system. This type of 
comparison exercise would likely be conducted by designers in the early phase of an AUV MCM 
system design, perhaps to initially scope the trade-space or to down-select among a set of broad 
concept alternatives. 
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Mission objectives 

Percent Search 

94% 

Search area dimensions 

Length: 4 nautical miles 
Width: 4000 yards 

Transit distances 

Ingress: 0 nautical miles 
Egress: 10 nautical miles 

Environment 

Bottom type category 

4 (gravel) 

Average water depth 

400 feet 

Mine threat 

Number of mines (estimate) 

25 

Fraction of undetectable mines 

0 

Mine target strength 

-30 decibels 


Table 4.1: Case One Scenario Inputs 


The analysis follows the procedure depicted in Figure 3-3. First, a fixed scenario is devel¬ 
oped for the evaluation and the MOE weights established for that scenario. Next, the system 
concepts are defined by specifying the appropriate parameters for each system. Once the sys¬ 
tem definition is completed, mission planning calculations are performed to determine the total 
mission time required to achieve the desired search objectives. Each AUV type is then designed 
to carry the required payload components and meet the endurance requirements demanded by 
the mission time requirement. From the system characteristics, the effectiveness and cost of 
each are determined and compared. 

The case scenario is based on a mine reconnaissance mission requiring a clandestine search 
in a 4 x 2 nautical mile area near the coast of enemy-occupied territory. An estimate of the 
number of mines and their average target strength is obtained through intelligence sources. The 
bottom type is known to be gravel, and the average water depth in the area is 400 feet. The 
concept of operations calls for the AUV system to be air-dropped adjacent to the search area, 
and picked up via surface ship after the mission at a rendezvous point 10 nautical miles from 
the area. Table 4.1 contains the input values for the scenario parameters. 

For this scenario, the MOE and sub-MOE weights are established as described in Section 
3.4.4. Referring to Table 4.2, the imaginary warfighter (a role played by the author for this 
case demonstration) regards Time and Mission Accomplishment as markedly more important 
than the other three upper-level MOE. The relative weightings for sub-MOE reveal that certain 
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MOE 

MOE Weight 

Sub-MOE 

Sub-MOE Weight 

Time 

0.45 

Effective Area Coverage Rate 

1.00 

Mission Accomplishment 

0.30 

Search Level 

0.60 



Localization Accuracy 

0.40 

Autonomy 

0.08 

Lift Support 

0.25 



Host Support 

0.75 

Communication 

0.11 

Reporting Frequency 

0.30 



Data Type 

0.70 

Covertness 

0.06 

Deployment Phase 

0.40 



Mission Phase 

0.35 



Recovery Phase 

0.25 


Table 4.2: Case One MOE Weights 


aspects of each top-level MOE are considered more important than others, such as the level of 
host support over lift support and type of contact data/information over the frequency of the 
contact reports. 

Two AUV MCM system concepts are evaluated. System One (SI) consists of a single 
AUV with several minehunting sensors, a robust navigation package, and radio frequency (RF) 
satellite communications gear. System Two consists of two different vehicle types, one of one 
type and two of the other, designed to operate as a cohesive unit. For the most part, System 
Two (S2) contains the same sensors, navigation units, communications gear, and other AUV 
sub-systems as System One. In this case, however, these sub-systems are distributed between 
the two AUV types. Vehicle Type One (VI) is designated as the “guide”. It possesses an 
ahead-looking sonar (ALS) and the same navigation and communication packages as the AUV 
in SI. It operates closer to the surface than the other vehicles in S2, allowing it to surface 
regularly for GPS fixes and RF communication without incurring the significant time delays 
it would if operating at a deeper depth. Vehicle Type Two (V2) houses a side-scan sonar for 
mine detection and classification, as well as a small video camera for identification (ID). For 
navigation, it has a basic gyro-compass and doppler velocity sensor (DVS), but does not have 
the capability to fix its position. Instead, it relies on the guide (VI), maintaining station relative 
to VI using an acoustic tracking system similar to an ultra-short baseline (USBL) array. The 
two vehicles of this type operate close to the bottom, at the optimum depth for the side-scan 
sonar, relaying contact data and imagery acoustically to the lead vehicle (for post-processing 
and further relay to the host). The system-level requirements/characteristics for Si and S2 are 
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identical, except for the number of vehicle types, of course. Table 4.3 summarizes the system 
definition. 

Table 4.4 displays the tactical parameters for SI and S2. The sonar performance metrics 
for minehunting are given in terms of characteristic search width, A; probability of detec¬ 
tion/classification, B; probability of identification; and false contact density (for classification) 
[15]. “A” and “B” are simplified parameters describing the effective swath of a sensor (A) 
and the associated joint probability of mine detection and classification (B). These values de¬ 
pend on parameters like sensor altitude, water depth, bottom type, and mine type. Likewise, 
“A” and “B” and the other sensing performance parameters are affected by information ex¬ 
change between sensors. This is why, for S2, the side-scan sonar performance values are slightly 
higher than for the same sonar in the case of SI. S2 was configured so as to achieve increased 
performance by using multiple, cooperating vehicles 1 . 

The inputs in Tables 4.1 through 4.4 were entered in the Input Module using the Mathcad- 
Excel program interface. 

4.1.2 Case One Results 

Following the entry of required case inputs, Systems One and Two were run through the Eval¬ 
uation Model one at a time. Costs for each system were estimated using the costing feature of 
the MCM Future Systems Working Group’s UUV Endurance Model. The results of each run 
were collected in an Excel output file for the comparison. Table 4.5 summarizes the results 
numerically. 

The results arc a mixture of real values (with units) and non-dimensional scores (on a scale 
"of 0 to 1). The former are largely the products of modeling to obtain MOE from MOP, while 
the latter are the result of MOP-MOE utility functions. Because of the manner in which the 
systems were defined, many of the parameters achieve the same h40E scores. The interesting 
comparisons are found in the effective area coverage rate, localization accuracy, lift requirement, 
and, of course, cost. Figure 4-1 illustrates a head-to-head comparison of these parameters. 

ipor System Two, the search width, A, of 588 yards is the assumed effective swath for the two side-scan sonars 
(one on each of the V2 AUVs) operating on adjacent tracks. The search width and operating altitude for V2 
were intentionally set so that the effective “A” of the following V2 AUVs matched the “A” of the VI AUV. 
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System Definition Parameters 

SYSTEM ONE 


SYSTEM TWO 


Single Vehicle, 

Multiple 

Multiple Vehicles, Distrib- 


Sensor 


uted Sensors 

Number of vehicle types 

i 


2 


Host-system comms method 

RF link via satellite or aircraft 

same 


Reporting frequency 

Periodic 


same 


System navigation fix method 

GPS via periodic surfacing 

same 


Contact position error threshold (yards) 

30 


same 


Reliability/redundancy level 

low - in-theater support required 

same 


Battery recharge method 

not required 


same 


Delivery method 

Air 


same 


Recovery method 

Surface 


same 


Vehicle Types 

S1V1: 

“LoneAUV” 

S2V1: ‘ 

Guide” 

S2V2: “Hunter” 

Number of vehicles, each type 

1 

1 


2 

Surfacing requirement? 

Yes 

Yes 


No 

Maximum length (feet) 

20 

20 


20 

Maximum diameter (inches) 

21 

21 


21 

Maximum weight (pounds) 

500 

500 


500 

Sonar suite 

(1) ahead-looking sonar 

(1) ahead-looking sonar 

(1) side-scan sonar 


(1) side-scan sonar 




Identification sensors 

Video camera 

None 


Video camera 

Navigation suite 

INS + D VS + GPS 

INS + DVS + GPS 

DR + DVS + acoustic 





tracker 

Communication suite 

RF antenna + acoustic 

RF antenna + acoustic 

acoustic modem 


modem 

modem 



Computer/processor 

Basic guidance and con¬ 

Same as System One 

Basic guidance and con¬ 


trol, kalman filter, sonar 



trol 


post-processor 




Battery type 

Silver-zinc 

Silver-zinc 


Silver-zinc 


Table 4.3: Case One System Definition Inputs 
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Tactical Parameters 

SYSTEM ONE 
Single Vehicle, 
Sensors 

Multiple 

SYSTEM TWO 
Multiple Vehicles, 
uted Sensors 

Distrib- 

Search velocity (knots) 

6 


6 



Transit velocity (knots) 

10 


10 



Navigation accuracy (% DT) 

0.05 


0.05 



Vehicle Types 

S1V1: 

“LoneAUV” 

S2V1: 

“Guide” 

S2V2: 

“Hunter” 

Vehicle Altitude (feet from bottom) 

300 

350 


100 


Search width, A (yards) 

ALS: 588 SS: 400 

ALS: 588 


SS: 588 


Probability of detection/classification, B 

ALS: 0.8756 SS: 0.80 

ALS: 0.8756 

SS: 0.90 


Probability identification 

0.95 

N/A 


0.95 


False contact density (per sqnm) 

1.0 

N/A 


0.5 


Track keeping accuracy (yards) 

5 

5 


10 



Table 4.4: Case One Tactical Parameter Inputs 


Sub-MOE 

System 1 

System 2 

Effective Area Coverage Rate (sqnm/hr) 

0.48 

0.77 

Percent Search 

0.977 

0.977 

Localization Accuracy (yds) 

15.0 

15.0 

Lift Requirement (sqft) 

18.4 

34.7 

Host Requirement 

0.0 

0.0 

Reporting Frequency 

0.7 

0.7 

Data Type 

1.0 

1.0 

Deployment Phase 

0.3 

0.3 

Mission Phase 

0.0 

0.0 

Recovery Phase 

0.0 

0.0 

Costs 



Production ($) 

225,167 

280,802 

Research and Development ($) 

492,791 

951,554 

Total System Cost ($) 

717,958 

1,232,356 


Table 4.5: Case One Results 
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Overall MOE vs Production Cost 
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Figure 4-2: OMOE vs. Cost Plot for Case One 

Up to this point, the results obtained for each system are given in terms of the lower-level 
MOE with no accounting for the weights previously established. For this example, a decision 
could possibly be made from the non-weighted results because only a few of them need to 
be compared and the decision-maker can apply their preference weighting mentally. For more 
complex situations, however, the weights may need to be formally incorporated into the results. 
One way to include the effect of the weights is to normalize each of the values on a 0 to 1 scale 
(if not already scaled) and then multiply the scores by the weights, as described in Section 
3.6.2. These weighted scores can then be rolled up into the overall MOE (OMOE) and plotted 
against some independent parameter such as cost, as done in Figure 4-2. 

The OMOE versus cost approach is attractive in the sense that it simplifies the analysis 
down to just two parameters for each system. The problem, though, is that a decision-maker 
probably can’t look at just two (or even a few) OMOE values and reach a conclusion as to 
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which alternative is most cost-effective. Unless the person evaluating the plot has a very good 
understanding of the model being used, and has observed the dynamics of the OMOE value 
as system parameters are altered, they will not be able to decide what OMOE difference is 
worth the associated cost difference. The OMOE versus cost plot is much more conducive 
to comparing a larger number of system alternatives. Case Two, which examines five system 
variants, provides a better opportunity to use the OMOE versus cost plot. 

4.2 Case Two 

4.2.1 Case Two Definition 

The Evaluation Model may be useful for exploring large sets of system concepts, where the 
number of systems makes direct parameter comparisons too difficult. Case Two examines a 
situation where the evaluator is trying to determine the effect (on cost and effectiveness) of 
slightly varying the mix of vehicles in the systems. The mission, scenario, and MOE weights 
from Case One apply. Five variants are formed by selecting from a pool of three basic vehicle 
types, each possessing their own baseline capabilities but configurable for a particular role in 
a system. For each variant, the number of vehicles and their role (i.e. sensing only, naviga¬ 
tion/communication only, or both) are also varied. Tables 4.6 and 4.7 summarize the system 
definition and tactical parameter inputs 14 . 

4.2.2 Case Two Results 

The results for Case Two are presented in Table 4.8 and Figures 4-3 and 4-4. The formats 
are identical to Case One, but several additional parameters are plotted to capture all of the 
interesting differences for this case. With five system variants, the direct comparison plots 
(Figure 4-3) reveal si gnifi cant differences between the systems, but do little to help the evaluator 
decide which is the most cost-effective (especially if the MOE weights are to be considered). 
This is where the OMOE plot comes in. As shown in Figure 4-4, the overall weighted MOE 
scores — one for each of the five systems — are plotted against both production and total cost, 

14 Systems 3-5 have two vehicle types. For each parameter, the input for the first type is listed on the top row, 
and the input for the second type is on the second row. 
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System Definition Pa- 

SI 

S2 

S3 

S4 

S5 

rameters 






Number of vehicle types 

1 

1 

2 

2 

2 

Host-system com ms method 

RF-Satellite 

RF-Satellite 

RF-Satellite 

RF-Satellite 

RF-Satellite 

Reporting frequency 

Periodic 

Periodic 

Continuous 

Continuous 

Continuous 

System navigation fix method 

GPS - surface 

GPS - surface 

GPS - link 

GPS - link 

GPS - link 

Contact position error thresh- 

30 

30 

10 

10 

10 

old (yards) 






Reliability/redundancy level 

High 

High 

High 

High 

High 

j Battery recharge method 

Not required 

Not required 

Not required 

Not required 

Not required 

Delivery method 

Air 

Air 

Air 

Air 

Air 

Recovery method 

Surface 

Surface 

Surface 

Surface 

Surface 

Vehicle Types 

Hunter 

Mini-hunter 

Guide 

Guide 

Guide 




Mini-hunter 

Mini-hunter 

Hunter 

Number of vehicles, each type 

2 

4 

1 

1 

2 




2 

3 

4 

Surfacing requirement? 

1 

1 

0 

0 

0 

Sonar suite 

ALS-21, SS-12 

ALS-12, SS-12 

None 

None 

None 




ALS-12, SS-12 

ALS-12, SS-12 

ALS-21, SS-12 

Identification sensors 

ID-MED 

ID-MED 

None 

None 

None 




ID-MED 

ID-MED 

ID-MED 

Navigation suite 

INS+DVS+GPS 

INS+DVS + GPS 

DR+DVS+GPS 

DR+DVS+GPS 

DR+DVS+GPS 




DR+D VS + tracker 

DR+D VS + tracker 

DR+DVS +tracker 

Communication suite 

RF 

RF 

RF 

RF 

RF 




Acoustic modem 

Acoustic modem 

Acoustic modem 

Compu ter/processor 

GC+K+S 

GC+K+S 

GC + S 

GC+S 

GC + S 




GC 

GC 

GC 

Battery type 

Li-Poly 

Li-Poly 

Li-Poly 

Li-Poly 

Li-Poly 


Table 4.6: Case Two System Definition Inputs 


Tactical Parameters 

SI 

S2 

S3 

S4 

S5 

Search velocity (knots) 

4 

4 

4 

4 

4 

Transit velocity (knots) 

6 

6 

6 

6 

6 

Vehicle Altitude (feet from bottom) 

50 

50 

300 

300 

300 




50 

50 

50 

Search width, A (yards) [ALS / SS] 

400 / 160 

200 / 160 

N/A 

N/A 

N/A 




200 / 160 

200 / 160 

400 / 160 

Probability of detection/classification, B [ALS / SS] 

0.5 / 0.85 

0.4 / 0.85 

N/A 

N/A 

N/A 




0.4 / 0.85 

0.4 / 0.85 

0.5 / 0.85 

Probability identification 

0.9 

0.8 

0.8 

0.8 

0.9 

False contact density (per sqnm) 

1.0 

1.5 

1.5 

1.5 

1.0 

Navigation accuracy (% DT) 

0.05 

0.05 

0.05 

0.05 

0.05 

Track keeping accuracy (yards) 

10 

10 

20 

20 

20 


Table 4.7: Case Two Tactical Parameter Inputs 
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Sub-MOE 

si 

S2 

S3 

S4 

S5 

Eff. Area Coverage Rate (sqnm/hr) 

0.32 

0.35 

0.26 

0.39 

0.98 

Percent Search 

0.939 

0.901 

0.901 

0.901 

0.933 

Localization Accuracy (yds) 

15.00 

15.00 

5.00 

5.00 

5.00 

Lift Requirement (sqft) 

42.88 

38.38 

23.71 

31.61 

27.00 

Host Requirement 

1.00 

1.00 

1.00 

1.00 

1.00 

Reporting Frequency 

0.70 

0.70 

1.00 

1.00 

1.00 

Data Type 

1.00 

1.00 

1.00 

1.00 

1.00 

Deployment Phase 

0.30 

0.30 

0.30 

0.30 

0.30 

Mission Phase 

0.00 

0.00 

0.00 

0.00 

0.00 

Recovery Phase 

Costs 

1.00 

1.00 

1.00 

1.00 

1.00 

Production ($) 

452,121 

290,348 

234,043 

240,595 

882,654 

Research and Development ($) 

492,792 

739,018 

1,371,346 

1,261,144 

629,390 

Total System Cost ($) 

944,913 

1,029,366 

1,605,389 

1,501,739 

1,512,044 


Table 4.8: Case Two Results 


providing a compact indication of the relative cost-effectiveness of each system. 

Unfortunately, the OMOE method is not so ideal as to provide a definitive answer regarding 
which system is “the best”. The decision-maker must determine the level of effectiveness that 
they are willing to pay for. The decision is further complicated by the presence of two different 
costs, one or the other of which may be more important for some reason. These cost-related 
preferences are not captured in the OMOE vs. Cost plots, nor are a number of other factors 
that could influence the decision. Still, the OMOE approach greatly simplifies the problem for 
the decision-maker, enabling them to apply judgement and reasoning in consideration of any 
remaining factors in order to reach a decision or conclusion. 
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Chapter 5 


Conclusion 


5.1 Summary of Work 

The main objective of this thesis was to develop an analytical framework for the evaluation 
of advanced search concepts for multiple-AUV MCM. Supporting objectives called for identi¬ 
fying suitable metrics for evaluating multi-AUV MCM systems, defining and constructing the 
evaluation framework, and demonstrating its functionality and usefulness. The pursuit and 
attainment of these objectives led to the following “deliverables”: 

• A recommended approach and associated methodology for evaluating unmanned/autonomous 
MCM systems, including multiple-AUV MCM systems. 

• An effectiveness model, for measuring the degree to which a set of mission objectives is 
satisfied according to the preference structure of the warfighter. 

• A system model, for transforming user-specified system requirements into a feasible design 
that is described by numeric values representing physical characteristics and performance. 

The evaluation approach uses MOP and MOE, and the relationships between them, to de¬ 
scribe a series of systems in terms of physical/performance characteristics and then to translate 
those characteristics into numeric values reflecting the mission-effectiveness of the systems. The 
mission-derived MOE are organized into a hierarchy and weighted, using AHP techniques, ac¬ 
cording to the warfighter’s preferences for a given scenario. Utility functions, modeling, and 
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simulation provide alternative means of relating these MOE to the system MOP. Implemen¬ 
tation of this approach involves two computer-based models: the Effectiveness Model and the 
System Model. 

The Effectiveness Model contains five MOE and eleven subordinate MOE which are intended 
to collectively portray the overall mission-effectiveness of any MCM system, but are especially 
geared toward unmanned/autonomous systems. Additionally, the model is meant to facilitate 
evaluation and comparison of MCM systems for all types of operations, including minehunting 
and min e clearance. Despite the intentions, the MOE selected may not be perfectly suitable 
for representing the present or future mission. A formal decomposition of the mission need by 
a panel of experts (using a QFD or similar technique) might reveal a different set of MOE. The 
Effectiveness Model can easily accommodate such replacements and modifications. 

The System Model provides the environment in which candidate AUV MCM systems are 
defined and characterized. Whereas the Effectiveness Model applies generally, the System Model 
handles a limited range of AUV concepts. The acceptable range of configurations is fairly broad, 
including single- and multiple-AUV concepts with various mixes of sensors, navigation packages, 
communications gear, batteries, etc. The more significant limits have to do with operational 
tactics and system behavior , and are summarized as follows. MCM operations are confined 
to minehunting — detection through identification, but not clearance. A system is assumed to 
operate as a cohesive unit, except that individual vehicles may conduct minor excursions for 
mine prosecution and/or navigation and communication. The time required for these excursions 
is added to the mission time. The search pattern is restricted to progressive runs along parallel, 
uniformly-spaced tracks (lawnmower pattern) in a rectangular search area. 


5.2 Applications and Future Work 

The models developed for this thesis are not, themselves, meant to be used for comprehensive 
evaluation of multi-AUV MCM system concepts. Instead, it is the framework - the approach 
and its associated methodology — that was developed with this intention in mind. The Effec¬ 
tiveness Model and System Model developed here serve mainly to demonstrate the approach. 
Two core applications for the evaluation framework were stated in Section 1.3. The first 
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application relates to AUV MCM system design and procurement decisions. The second ap¬ 
plication has to do with operational employment of a given system, assuming it already exists. 
For both applications, the evaluation framework helps to guide exploration of the vast trade- 
space associated with AUV MCM system concepts, with the ultimate goal being to identify the 
most effective design, configuration, or employment alternative as weighed against some cost(s), 
monetary or otherwise. In the design/procurement case, the framework provides a means of 
designing to mission-effectiveness, rather than optimizing the design to a set of performance 
specifications. This is a very powerful approach because it enlightens the designers, allowing 
them to observe and understand the impact of engineering decisions on the ultimate usefulness 
of the end product. By gaining this insight early in the design process, costly re-work, due to 
uninformed decisions and/or changes in the mission requirements, can be minimized. Regarding 
the employment application, the framework offers an opportunity to explore a much larger field 
of operational paradigms than would be examined during the design process. This may include 
assessing different system configurations (formed by mixing and matching re-configurable ve¬ 
hicles and sub-systems) and altering tactical parameters (e.g. speed, search pattern, contact 
prosecution algorithms) under a variety of scenarios. 

A significant milestone for the evaluation of multi-AUV systems, for any mission, will be 
the development of a high-resolution, high-fidelity modeling/simulation environment in which 
a broad range of system concepts can be consistently and accurately evaluated in terms of 
mission-effectiveness and cost. The Effectiveness Model and System Model represent a step in 
this direction, but much work remains. In particular, the limitations of the System Model should 
be addressed. While a “static” analytical model appears to be sufficient for describing most of 
the physical characteristics of a multi-AUV system, and perhaps the basic aspects of individual 
vehicle performance, simulation may be preferable for addressing the more complex and time- 
dependent issues associated with tactical and operation employment. For example, a simulator 
could replicate exotic search algorithms that enable the multi-AUV system to change tactics in¬ 
stride, say, in response to changes in bottom clutter density. Simulation capability may also be 
used to augment a static model. In the case of the System Model, the sensing and/or navigation 
performance of multi-AUV systems could be provided by a simulator designed for that specific 
purpose, thus relieving the user of this burden and allowing more unusual system concepts 
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to be explored. High-fidelity performance simulators for critical areas (sensing, navigation, 
communication, etc.) will be essential to the implementation of a comprehensive multi-AUV 
MCM system evaluation framework. 

While improvements in the framework’s technical capabilities are important, more criti¬ 
cal areas for future work relate to the types of analyses that can be performed and the na¬ 
ture/presentation of the information provided by the framework. For example, the Evaluation 
Model supports high-level, effectiveness-based comparison of any number of system concepts, 
but lacks the internal relationships and consistency checks necessary for detailed sensitivity 
analyses. Incorporating the capability to adjust individual system parameters and immediately 
observe the impact on mission-effectiveness over a range of inputs would significantly enhance 
the power of the evaluation framework. 

5.3 Closing 

This thesis represents more than the individual effort of the author. Many people graciously 
contributed to this work, providing technical information, expert advice, general guidance, 
and just plain old support. Perhaps the most rewarding part of this experience has been the 
fascinating dialog that resulted from interacting with members of, and contributors to, the 
Navy’s mine warfare community. It is the author’s hope that both the process and the final 
product serve to benefit the community and the persons associated with it. 
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Appendix A 


AUV MCM System Evaluation 
Model Technical Information 


The Evaluation Model template resides in three distinct Mathcad files. One file is dedicated to 
the Effectiveness Model (Appendix C); the other two files contain the System Model (Appendix 
B). The AUV Design Module is separate from the Input and Mission Planning Modules so that 
multiple AUV types can each be modeled in a unique file. Imbedded in the System Model is 
an Excel file that contains a user interface sheet (part of the Input Module) and a series of 
databases for AUV sub-component characteristics (see Appendix D). 

The Mathcad files are connected through “reference links”, allowing information to flow 
from the Input and Mission Planning Modules to both the AUV Design Module and the Ef¬ 
fectiveness, as illustrated in Figure A-l. Each reference link must be manually updated if the 
reference filename changes. Similarly, the three output (file write) components at the end of 
the Effectiveness Model should also be updated so that the new output files are created with 
the desired filenames. It. is recommended that the output components be disabled before the 
new Effectiveness Model file is created in order to avoid overwriting other output files. 
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Figure A-l: Evaluation Model File Structure 
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Appendix B 


System Model 


SYSTEM MODEL 


Model Description 

The System Model is the starting point for an evaluation problem. It has two main purposes: 

(1) To provide an environment in which to design/configure a notional AUV system 

(2) To determine the system MOP required as input to the Effectiveness Model 

Three modules make up the System Model: 

- INPUT MODULE: Scenario and tactical parameters are entered in the Mathcad worksheet; system-level 
and vehicle/paylod entries are made in an Excel worksheet through a link. The Excel sheet contains 
databases with AUV sub-system weigth, volume, and power data. 

- MISSION PLANNING MODULE: Calculates total mission time required to achieve Percent Search 
objective, as well as the actual (achieved) Percent Search (almost always greater than the objective). 

- AUV DESIGN MODULE: This module resides in a separate file in order to accommodate the design of 
multiple AUV types. 


Constants 


dB := 101og( weber-m 2 10 12 - weber ^m 2 ) 


nm := 2025yd 


knt 


nm 

1-hr 


68 


I. MISSION AND SYSTEM INPUTS 


A. Scenario Parameters 

1. Mission Objectives 

Minehunting Objective: Mission Type Typical Objective P search_desired : “ 

Exploratory first-look xx 

Given as "Percent Search" achieved through Basic reconnaissance xx 

minehunting for detection, classification, and Detailed mapping xx 

up through identification. Enter fractional 
values as illustrated in guide table at right. 


Search area dimensions: 


Specify delivery/recovery methods (e.g. 
air, sub, surf) through Excel link below. 


Distance from point of entry to search area: 
Distance from search area to recovery point: 


^earcharea : ~ 3 nm 

W searchar ea:==400fyd 


^ingress •*” 


2. Environment 
Bottom Type: 


Bottom Tvoe Number Desiq 

Gravel 4 

Sand 9 


BT := 4 


Average Water Depth: 


u avg •' 


:40Gft 


3. Mine Threat 

Estimated number of mines in search area: NM := 25 

Fraction Of undetectable mines: Zero entry is best for comparisons, and is appropriate p ;=I0 

if the individual sonar detection probabilities {B 
values) account for undetectable mines. Entering a 
value here implies that a certain fraction of mines are 
undetectable by ALL of the sensors in the system. 

Mine target Strength: This parameter is used only as a reference for Sonar y ;= ~30dB 

Performance Parameter entries (Section I.C.3). 


B. System Definition 

1. Excel Input Link 

Double click on the icon Enter inputs in yellow-shaded areas 
of interface worksheet inside Excel. Use database sheets to 
guide input When finished, save and close the link. Click once 
on the icon and press F9 to update Mathcad with the new info. 


( sysreqs ^ 
vehreqs 
\ payload j 



Worksheet 
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System-Level Requirements 


Comments/Legend 


Number of vehicle types 


Host-system com ms method 


Reporting frequency 
System navigation fix method 


Contact position error threshold (yds) 
Reliability/redundancy 


Battery Recharge method 
Delivery method for clandestine ops 


Recovery method for clandestine ops 


2 Selection must agree with number of entries in "Vehicle Requirements section 
RF-SAT AM=acoustic modem, RF-LOS=radio freq via line of sight, RF-SAT=radio freq via satellite or aircraft,NR=not required 

PRD CONT=continuous, PRD=periodic, NR=not required Note: enter achievable reporting frequency based on comms method 
and opportunity to report (e g. surface to transmit RF, host within AM range, etc.) 

GPS-SURF GPS-SURF=GPS by surfacing, GPS-LINK=constant GPS (e g. buoys or antenna), LBL=Long Baseline or other array, 
NOFIX=DR only Note: enter method for system, regardless of which vehicles are invotved in actual position fixing 
30 Maximum acceptable distance between actual and reported contact positions.Note: set value to reflect the achievable 
threshold using fix method prescribed above 

LOW LOW^system requires an in-theater support platform during search phase;HIGH=system does not require a support platform 
in theater during search phase or is expendable. 

NR HOST=vehicles rely on host platform for battery recharge;DOCK=battery recharge via in-water docking stations or 
equivalent system; NR=not required (i.e. endurance is greater than mission time) 

AIR SUB=submarine, AIR=aircraft, SURF=surface ship Note: same for all vehicles in system 

SURF SUB=submarine, A!R=aircraft. SURF=surface ship Note: same for all vehicles in system 


I Vehicle Requirements and Payload 

Item Units 


Type/Role 
Number of vehicles (this type) 
Surfacing requirement toggle 
Max Length 
Max Diameter 
Max Deadweight 
Sonar#1 
Sonar #2 
Sonar #3 
ID Sensor 
Nav Suite 
Comms 

Computer/Processor 
Battery Type 
Sensor Suite Weight 
Sensor Suite Volume 
Sensor Suite Power 
Nav Suite Weight 
Nav Suite Volume 
Nav Suite Power 
Comms Suite Weight 
Comms Suite Volume 
Comms Suite Power 
Computer/Processor Weight 
Computer/Processor Volume 
Computer/Processor Power 
Battery Specific Energy 
Battery Energy Density 
Battery Weight to Volume Ratio 


Vehicle Number 
2 3 


guide 

1 

1 

20 

21 

500 

ALS-21 

0 

0 

0 

INS-DVS-GPS 

AM+RF 

GC+K+S 

Ag-Zn 


ar 

■ r r 

cuin 146.6 

| watt . 23.0 

: cuin 61.7 

l ' watt ■' ii 

■ SSS, Z, 

IWcuft 124.9 

User must ensure that payload 


hunter 0 

2 0 

0 0 

20 0 

21 0 

500 0 

SS-12 0 

0 0 

0 0 

ID-LOW 0 

DR-DVS-ABR 0 

AM 0 

GC 0 

Ag-Zn 0 

• ,>fmA lllll -o.o 

41.0 0.0 

20.6 0.0 

0,0 ; r ^ ; 

..... :: ' -. 

1.5 0.0 

- ■'%/:S7.0 i' - -'' ■ -0.0 ; - 

| 75JI : "ftO 
15.0 0.0 

0.0 


0 

0 

0 

0 

0 

0 

0 

0 

0 

o 

0 

o 

o 

0 

0.0 

0.0 

0.0 

- § 

'6: ' -'J 


Comments/Legend 


Choose differentiating name 
1 if yes, 0 if no 

Ensure consistency with system reqs; zero if no limit 
Ensure consistency with system reqs; zero if no limit 
Ensure consistency with system reqs; zero if no limit 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
Use exact desig from database 
I NOTE: check these lookup formulas if databases changed 

|| assume 100% duty cycle 


J assume 100% duty cycle 


: | assume 100% duty cycle 


I assume 100% duty cycle 


components' diameters correspond with max vehicle diameter 
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2. System Requirements 



Variable assignment: 

submatrix(A, ir,jr,ic,jc) returns the matrix consisting of rows ir through jr 
and columns ic through ic of array A. 
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type :=if(numtype as 1 , vehreqs 1>numtype+2 ,submatrix(vehreqs , 1 , 1,3, numtype + 2)) 
numveh :=if(numtype = l,vehreqs 2 in umtype+ 2 » submatrix ( vehre( l s ,2,2,3,numtype + 2)) 
surf_req := if(numtype = 1,vehreqs 3?niirntype+2 ,submatrix(vehreqs ,3,3,3,numtype + 2)) 
Lmax:= numtype a l,vehreqs 4 numtype+2 ,submatrix(vehreqs ,4,4,3,numtype + 2))-ft 
Dmax:= if(numtype = 1,vehreqs 5?numtype+ 2 ,submatrix(vehreqs ,5,5,3,numtype + 2))-in 
Wmax:= if(numtype = 1,vehreqs 6 numtype+2} submatrix(vehreqs ,6,6,3,numtype + 2))lb 


type = ("guide" "hunter" ) 
numveh = (1 2) 
surf_req=(l 0) 

Lmax= (20 20) ft 
Dmax=(21 21) in 
Wmax = (500 500) lb 


4. Vehicle Payload 

From spreadsheet link: 



1 

2 

3 

4 

1 

"Sonar#1" 


"ALS-21" 

"SS-12" 

2 

"Sonar #2" 


0 

0 

3 

"Sonar #3" 

H M 

0 

0 

4 

"ID Sensor" 

It ft 

o ! 

"ID-LOW" 

5 

"Nav Suite" 


5-DVS-GPS" 

*-DVS-ABR" 

6 

"Comms" 

i?_jrt 

"AM+RF" 

"AM" 

7 

r/Processor" 

H II 

"GC+K+S" 

"GC" 

8 

attery Type" 


"Ag-Zn" 

"Ag-Zn" 

9 

uite Weight" 

"lb" 

20.3 

7.175 

10 

jite Volume" 

"cuin" 

924 

718.38 

11 

Suite Power" 

"watt" 

139.4 

41 

12 

uite Weight" 

"lb" 

9.969 

20.55 

13 

jite Volume" 

"cuin" 

146.51 

719.753 

14 

Suite Power" 

"watt" 

22.95 

24.25 

15 

uite Weight" 

"lb" 

2.5 

1.5 

16 

jite Volume" 

"cuin" 

61.714 

37.029 

17 

Suite Power" 

"watt" 

12 

9 

18 

>sor Weight" 

"lb" 

4 

2 

19 

sor Volume" 

"cuin" 

300 

75 

20 

ssor Power" 

"watt" 

40 

15 

21 

oific Energy" 

"watt-hr/lb" 

40.824 

40.824 

22 

rgy Density" 

watt-hr/cuft" 

5.097-103 

5.097-103 
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Variable assignment: 


W sensors : = if ( numt yp e = 1,payload 9>nuintype+2> submatri)<payload,9,9,3,numtype + 2))-lb W sensors = (20.3 7.175) lb 

V sen$ors :== iflfnumtype = 1,payload 10>numtype+ 2 ,submatri)<payload, 10,10,3,numtype + 2))-in 3 V sensors = (924 718.4) in 3 

Psensors : = if ( numt yp e = 1 ,payload! lt numtype+2 ,submatri?<payload, 11,11,3,numtype + 2))-watt P sen sors = ( 139 - 4 41) watt 

W nav := if(numtype = 1, pay load l 2 ,numt y pe+ 2 > s ubmatrix(pay load, 12,12,3, numtype + 2))-lb = (9.969 20.55) lb 

Vnav := if(numtype as 1, payload j 31 numt ype+2»submatrix(payload ,13,13,3, numtype + 2)) * in 3 V nav — (146.5 719.8) in 3 

P nav := if(numtype a 1,payload , 4> numtype+2 ,submatri)<payload, 14,14,3,numtype + 2))- watt P nav = (22.95 24.25) watt 

W comms if(numtype a 1, payload 15> numtype+2 , submatrix(payload ,15,15,3, numtype + 2)) lb W comms = (2.5 1.5) lb 

V comms :=if ( numt yP e = 1, payload l6 numtype+2 ,submatrix( pay load, 16,16,3, numtype + 2))-in 3 V comms = (61.7 37)in 3 

Pcommsif(numtype a 1,payload 17 numtype+2 ,submatri>(payload, 17,17,3,numtype + 2))-watt P comms - (12 9) watt 

W computer := if( numtype a 1, payload j 8 fnumtype+2 , submatri>(payload, 18,18,3, numtype + 2))lb W computer =(4 2) lb 

^computer := if(numtype a 1,payload I9< numtype+2 ,subrnatri)<payload ,19,19,3,numtype + 2))-in 3 V computer - (300 75) in 3 
P computer •“ if^numtype a 1,payload 20 numtype+2 ,subrnatrij<payload,20,20,3,numtype + 2))-watt P compu t C r = ( 40 15 ) watt 

Vbatteiy :=if ( numt yp e ■ 1,payload 2 j t numtype+2 , submatri^payload ,21,21,3,numtype + 2)) — Ybattery = (40.824 40.824) Wa ^ h 

, v watt-hr watt-hr 

Pbattery := if(numtype a l,payload 22 numtype+2 ,subrnatri5<payload,22,22,3,numtype + 2)) -— Pbattery = ( 5097 5097 )-- 

ft 3 ft 


C. Tactical Parameters 

1. Speed and Endurance 

Search Speed: 
Transit Speed: 
Prosecution speed: 

2. Search Parameters 
Vehicle Altitudes: 


Note: This version of the model assumes the following: 

(1) all vehicles In the system move together at the same speed 

(2) all vehicles must have enough endurance to complete mission 

Ysearch*” 6knt Average system search speed; individual 

vehicles may travel at different speeds. 

^transit :== 10knt Vehicles assumed to transit en masse 

Vprosecme := V^i, Speed at which ID-tasked vehicle(s) 

prosecute mine-like contacts; this can be 
adjusted to "even out" vehicle mission 
times (computed at the very end of this 
model). Should not go above \£ ansit . 


ALT(350 100 0 0)ft 


ALT must not exceed 
avg depth. 



73 




3. Sonar Performance Parameters 


1. Enter sonar performance parameters FOR EACH SONAR in terms of the characteristic search width "A" and characteristic 
probability of detection/classification "B". [These simplified values can be derived from a "probability of detection as a 
function of lateral distance", or P(y) curve; Reference PEO(MIW) INST 3370 for definition of these parameters.] 

2. The following reference parameters are provided for looking pre-determined up the "A" and "B" values (reference MCM 
Future Systems Study for some notional ALS, SAS, and SS sonar values): 

vehicle altitude (ALT) search speed (Vs) 

bottom type (BT) target strength ( 7 ) 

water depth (d avg ) 

3. For cooperative multi-AUV operations, the A and B values can be adjusted to reflect the "effective" performance due to 
more efficient search tactics and/or increases in search probabilities due to communication between vehicles, data fushion, 
multi-static operations, and so forth. 

Reference Parameters: Sonar_Suite := submatrix(payload, 1,3,1,6) 


!" ' . ( "Sonar#1" "ALS-21" "SS-12" 0 0 N 


Sonar Suite = "Sonar #2” 


\ "Sonar #3" 


" 0 


0 0 0 

°; 0 °' 


V_. K - 6knt 


ss (350 100 0 0)ft 


,y«-30dB 


Sonar Parameter Entry: 


Vehicle types 


Characteristic Search Width 


^588 588 0 0 | Sonar 
A := 0 0 0 0 yd types 

i 0 0 0 0 j 


Characteristic Probability of Detection/Classification b := 0 


0.8756 0.95 0 0 


0 0 0 
0 0 0 


Probability of identifying a mine as a mine 


P •= 95 

r imm * 


False contact density for identification 


^inm ■= lnm 


Must be less than total 
mine density 


i •. NM . * _ ■ -2 

. .. . . .= 4.219nm , 

| t-searchorea^searcharea 


4. Navigation Performance Parameters 


Navigation "growth error" (for system): %DT := 0.05 

Standard deviation of track keeping: a:=(5 10 0 0)yd 


<*1,1 <*1,2 <*1,3 <*1,4 

a := ai i aj2 <* 1,3 a i,4 

^<*1,1 <*1,2 <*1,3 <*1,4, 
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II. MCM MISSION PLANNING MODULE Based on Uniform Clearance (UCPLN) 

-“ Theory (ref. PEO(MIW) INST 3370) 

A. Probability Parameters 

1. Non-dimensionalization 

Act ^ W search area ^ ^ ^track 

A nd : = “T CT nd :=- 7 D track-= ~ D track.nd := , 

yd yd N yd 


Note: N = number of tracks, a 
global variable defined at 
Section il.C. 


2. MCM Efficiency Coefficient 

Y is the coefficient of MCM efficiency. In simple terms it is the payoff from covering the area in an orderly manner, rather than 
randomly. As randomness decreases (B increasing or <*decreasing) Y increases. This equation was derived by Dr. R.K. Reber 
many years ago by averaging the probability of clearance between two parallel tracks in the central part of the channel where 
there were no edge effects; i.e., the channel edges were far enough away to the left and right that extending the width of the 
channel would have no effect. 


Y := 


for i € 1.. rows(A) 
for j e 1.. cols (A) 


2* <Tnd. 


yi, 


A nd. ,‘®i,j 


roc 

- 

( 

r A nd . > 


/ 

A nd ' 

y 

In 

1 - Bj r 

cnorm 

u + - i±- 

- cnorm 

u - 

-1sL 





2-a nd 



2-Cnd 



_ 

V 

V '•<> 


V 

UlJ 

J. 


du if Bj j * 0 


y 


Y = (2.357 3.066) 


3. "M" Terra 

M represents a combination of the level of coverage {the search width, A, times the number of 
runs, J, divided by the drack spacing, D) and the success of detection/classification over the area 
covered (probability, B). 


M := 




for j g 1.. cols(A) 

J‘ A nd *®i,j 

^track.nd 


if B, 


m 


M = (0.901 0.978) 
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C. Required Search Parameter Values (to achieve desired Percent Search) 

Adjust to get desired P searctT 

Required number of tracks: 

Number of runs per track: 

Track Spacing: Ensure D track is less than 

the smallest non-zero A value 


D. Mission Time 





1. Transit Time 





Transit distance: 

^transit 

^ingress + ^egress 

^transit 

= 6nm 

Transit time: 

T 

1 transit 

^transit 

^transit 

T 

1 transit 

= 0.6hr 
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2. Search Time 


Total track distance: 


dtrack runs•— f-searcharcaN'J 


d track runs — 21 nm 


Total turns distance: 


dtums := t(N'J) - l]*D track * 1.1 assumes 10% "excess- 

on each turn 


Search distance (incl turns): d scarc h:= <W runs + d h 


drums = 1.862nm 


dscarch” 22.9nm 


Search time: 


T search •“ " 


Tsearch~ 3.8lhr 


3. Comm/Nav Excursion Time 


System common parameters: 


Nav/comm reqs (from input): fixjmethod = "GPS-SURF" 

report_freq = "PRD" 


"No fix” interval: applicable to systems d no f lx := 

with fixing capability 


max_pos_error 


d„ 0 fix = 600yd 


Frequency/number of fixes: 


Nfixes = 70.875 


Vehicle parameters (arrays indicate values for specific vehicle types): 


Vehicle surfacing rqmts (from input): surf req = (1 0) 


1 = surf req, 0 = no surf req 


Number of surfacing evolutions: 


Nsurf : ~.Nf lx 


assumes number of fixes dictated 
by nav requirements 


Time on surface (typical value): 


Txmit recv := Osec 


(enter zero if negligible) 


Ascent/descent rate (typical value): ascent descent_rate ^ 200- 


Distance to surface: * alt := if(numtype = 1,ALTi j,submatrix(ALT, 1,1, l,numtype)) 

alt = (350 100) ft 


dsurface*" - d av g alt 


d S urface=(50 300) ft 


Ascent/descent time: 


1 ascent descent <— 


2d su rface 

ascent descent rate 


Tascent descent— (0*5 3 ) min 
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Excursion time summary: x e 
(for each vehicle) 


for i e 1 .. numtype 

xj i surf_req i i - N SUI f ^T ascen t descent + T xm it_recv^ if numtype > 1 
x ■<— surf_req ■ N sur f (T ascent _d eS cent + T X mit_recv) otherwise 


1 = (0.591 0) hr 


Check against search time: 


!W h -3.Slhr 


If excursion time is unreasonable, vehicle altitude and/or number of fixes may 
need to be adjusted. If necessary, override with estimate based on search time? 


4. Prosecution Time (for identification) 


IMM-25 




Number of ID attempts: 


i * — [jNM * (1 M-) + ^inm' W searcharea Lsearchareaj * 


NIA = 27.227 


Identification time (per attempt): t 


0.5Dtrack‘2 


Tmine ID — 1.693min 


Assumptions (state if formula changed): 

1. Typical prosecution will involve one vehicle transiting about half the track distance, including both 
horizontal and vertical distance to the contact from the search track. 

2. Multiply by 2 for return to place in formation. 

3. Prosecution speed set in Section I.C.1; can be adjusted to match overall system mission time (see 
sub-section 5 below). 


Total identification time: 


TprosecuteNIA*T m j ne :id 


T prosecute —0.768hr 


Prosecution time: 


IDSensors := submatrix(payload,4,4,3,6) 


(for each vehicle) 


lD_Sensors = (0 "ID-LOW” 0 0) 


Tprosecute «= for i e I.. numtype 

Xj ( i ^ Tprosecute if ID_Sensors l ( i ^ 0 


Tprosecute — (0 0.768) hr 


5. Mission and Endurance Time 


Estimated vehicle mission times: 


T miS sion_vch_est = (5.001 5.179) hr 


Review these times to ensure they fit the system CONOPS. For example, if the system is intended to search as a unit, 
then the mission times for each vehicle type should be dose. In reality, vehicles with special assignments (like 
surfacing or prosecuting) may speed up or slow down to regain position. These cases may be somewhat accounted for 
by adjusting the prosecution speed for the ID vehicle(s) (Section I.C.1). Remember that this will effect the amount of 
energy required by that/those vehicles as computed in the AUV Design Module. 


Total mission time for system: 


, := ma^T^ 


:h_est) 


t : , I79hr 

f 1 mission 117111 


Required vehicle endurance time (same for each type): 

T endurancereq := ^ *5-nia3^T m j ss j on ve j,_ est ) 

Include margin 


^endurancereq “ 7.768hr 


III. AUV DESIGN MODULE 

Individual AUVs are designed in separate .mcd files that reference the System Model for inputs. 
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AUV DESIGN MODULE 


Model Description 

The AUV Design Module is a sub-components of the System Model, and is used to design each 
vehicle type. The modeling approach is derived from the MIT 13A SSN Math Model, a submarine 
design tool based largely on parametric studies performed by CAPT Harry Jackson, USN (Ret). 


Constants Caution: constant are carried into this mode! through the reference links as well; be 

sure to avoid conflicts by check System Model "Constants" section. 

lton := 22401b 

fcurve ~ 1*176 
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I. INPUTS 


UPDATE REFERENCE LINK PATH - DELETE LINK AND 
INSERT NEW ONE (USE "RELATIVE LINK" OPTION) 


Enter number corresponding to vehicle 
being modeled in this worksheet (i.e. 
for first column of numbers, enter "1") 


@ Reference:C:\My Documents\MIT\Thesis\Modeling\Master\System Model - Master.mcd(R) 


^ scnsors = (20.3 7.175) lb 

w •= W 

¥V sensors sensors, 

l >v 

V scnsors =(924 718.4)in 3 

V •= V 

v sensors- v sensors 

1 ,v 

^sensors = ( 139.4 41) watt 

P *=P 

1 sensors ‘ A sensors, 
l,v 

W nav = (9.969 20.55) lb 

w •= w 

vv nav * yy nav, 
l,v 

V nav = ( 146.5 719.8) in 3 

V ■= V 

V nav * V nav ) y 

P nav = (22.95 24.25) watt 

P *=P 

r nav * 1 nav, 

l.v 

W comms = (2.5 1.5) lb 

w •= W 

vv comms • vv comms ^ y 

V C o mms = (61.7 37) in 3 

V •= V 

v comms * v comms, 

1 ,v 

Pcomms = (l 2 9) watt 

r comms ' 1 comms { ^ 

W computer =(4 2) lb 

^computer* - W compute^ v 

V comput „= (300 75) m 3 

^computer * — Ycompute^ y 

Pcomputcr=( 4 0 15) watt 

r computer* * compute^ y 

^ watt-hr 

7battery = (40.824 40.824) )b 

Ybattery *~ Ybattery t v 

watt* hr 

Pbattery ~ (5097 5097) 

ft 3 

Pbattery * — Pbattery t ^ 

Texcursion= (0-591 0)hr 

1 excursion 1 excursion v 

prosecute” (0 0.768)hr 

^prosecute *” ^prosecute^ v 

Power Requirements 


1. Initial Power Estimates 


Mission time (estimated in System Model): 

Tcodurancc.C 7 - 7681 * 


Hotel power (based on payload input): 

PHotelReq * — ^sensors ^ ^nav + Pcomms ^computer ^HotelReq 

^HotclReq PHotelRcq'^endurance req ^HotelReq 


214.35 watt 
1.665kW-hr 
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Propulsion power estimate: 



2. Propulsion Power 


Motor selection: 

PpropPeakestPprop_est(%ransit) 

Used to guide motor selection; use max 
sustained speed (e g. transit speed, burst 
speed, etc.) 

Est. peak propulsion pwr: 

&W>eaM» = 3.2nhp 

Max vehicle diameter: 

^MotorRating •” 

Select motor power rating using peak propulsion 
power estimate (left). Check Vmax in Section V.< 
to ensure it is sufficient (i.e. greater than all 
required speeds). 

D msx ~ 21 in 

^motor 

Enter motor diameter corresponding to power 
rating. Must be less then max vehicle diameter. 

Power Volume Density: 

watt 

Pprop :=3500— 
fr 

Enter propulsion plant volume density (include 
support systems and components) 

Power Weight Density: 

watt 

Yprop 40 lb 

Enter propulsion plant weight density (include 
support systems and components) 






Checks (from MCM WG model): rho : = ■ ? -- Q72ft 

0.2&W 


rho = 0.257 


ft 

kW 


— = 3889 
rho 


watt 



gamma 


7.61b 

0.2&W 


gamma - 27.143' 


Jb_ 

kW 


1 _ _ . watt 

-= 36.842- 

lb 


gamma 


3. Energy Source 

Estimated required energy: 

Installed energy: 

Battery specific energy: 
Battery energy density: 


^Missionest •” ^HotelReq Eprop_est 


EMission est ~ 5.98kW-hr 


^Installed — 9.5kW*hr 


Ybattery — 40.82 


watt-hr 
lb 


P battery — 5097 


watt-hr 


B. Payload Weight and Volume Inputs 


1. Payload Weights 

W sensors = 20.31b 

w nav = 101b 

W comms = 2.51b 


W computer 4 lb 


2. Payload Volumes 

V sensors = 0.535ft 3 
V nav = 0.085ft 3 
Vcomms = 0.036ft 
^computer = 0.174ft 3 


C. Other Inputs 

Internal Structure and Arrangement 

Internal Structure Factor SF := 0.2 

Volume Packing Factor (Dry Hull) PFdry := 1.0 
Volume Packing Factor (Wet Hull) pFwet := 0.1 


Internal structure volume as fraction of payload volume 


Applied to dry volume subtotal to account for component 
spacing, free floods, growth margin, etc. 


Applied to wet volume subtotal to account for component 
spacing, free floods, growth margin, etc. 


Ballast Factor 


Reserved ballast volume as fraction of pressure hull volume; 
assumed to be for "hard" variable ballast tanks. 
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II. VOLUME REQUIRED 

A. Preliminary Volumes Calculations 


v battery • 


■^Installed 
P battery 


^propulsion * — 


r MotorRating 

Pprop 


V batteiy = 1.864ft 3 
^propulsion = 0.639ft 3 


B. Dry (Pressure) Hull Volumes 

Payload and other vehicle components for pressure hull: V nav = 0.085ft 3 

Select appropriate components from Sections I.B.2 and IIA _ . . 3 

Ensure following equations include appropriate items. computer — 

^battery = 1 -864ft 3 

V propalsi on = 0.639ft 3 


Standard pressure hull items: 

Vdryjntemal_stmcture := SF*(V nav + V computer + V battery + V propulsion ) V dry_in temalj>tructure = 0.552ft 


Pressure Hull Volume: 

Vp H :=(1 + PFdry) (V nav + V computer + V battery + V propu j s i on + V dry j ntema i_ structure ) 

C. Wet Hull Volumes 

Payload and other vehicle components for wet hull: 

Select appropriate components from Sections I.B.2 and 1 LA 
Ensure following equations include appropriate items. 


V sens0 rs = 0.535ft 3 
V comms = 0.036ft 3 


Standard wet hull items: 

^wet_intemal_structure * = ^F- (V sensors + V comms ) ^wet_intemal_structure 

V ballasttank := BF-V PH V ballast ank = 0.663ft 3 


Wet Hull Volume: 

VwH := (1 + PFwet).(V senS or S + V comms + V wet j nIema ]_ structure + V b allast_tank) 


6.627ft 3 


= 1.482ft 3 
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D. Everbuoyant Volume 


v eb Vp H 4- V sensors + V comms + V wet j nteraa i structure + ^ballast_tank 

E. Submerged Volume and Displacement 

Assumes "hard" ballast tanks, i.e. no change in displacement for 
submergence--only weight is changed. 

As := V s -p sw 

F. Required Envelope Volume and Displacement 

Y en vr := V PH + V WH Appendages (i.e. control surfaces, antennas, etc.) are not included. 
A envr * = Xenvr* P SW 


V eb = 7.975ft 3 

V s = 7.975ft 3 
A s = 510.3731b 

V envr = 8.109ft 3 
Aenvr= 518.9961b 


111. ENVELOPE VOLUME AVAILABLE 

A. Spin a Hull: 

Based on the volume requirements calculated in Section II, select L, D, length of parallel mid-body, and forward & aft shape factors. 


Select D: 
Select L/D: 


D = 2 tin 


LOD= 6 


L:= LODD 


Optimum - 6 


Constraints: Based on user entries in AUV System Mode! 

and component sizes 

D m j n •= niax(D m j n , D motor ) ^ 


Lmax^ v = 20 ft 


D “''' 75ft 


L„ax := if(numtype > 1 ,Lmax,, v.Lmax) = 20ft 



D check := i{(D < D max a D > D min ),"OK","RESIZE"] 
Loheck- >t( L * Lmax, "OK" /’RESIZE") 


Use following section to adjust nose, tail, and parallel midbody lengths. 


Entrance: 

r| f := 2.25 Optimum = 2.25 


Run: 

rj a :=2.75 Optimum = 2.75 


Nose length: 

Lf := 2.4 D Optimum = 2.4*D 

4 = 4.2ft 

Tail length: 


4 = 6.3ft 

Parallel midbody: 

Lpmb := (LOD- 6)-D 

© 

II 

.o 

I 


Length :=Lf+ L,+ Lp mb 

Length = 10.5ft 





B. Volume Calculations to Support Arrangement: 


1. Entrance: Lf^ 4.2ft 


yfl(xl) := 1 


xl := 0-ft,. l-ft._ Lf + Lp mb 

Lf-xiy f D , 

Lf I 2 offf(xl) := iff xl < Lf,yfl(xl) 


2. Run: 


4 = 6.3ft xl:=0-ft,.lft..L 


ya(xl) := 1 


xl -(Lf+Lpm^T 8 D 


3. Total Ship: 0 fft(xl) := if(xl < Lf + Lp mb ,offf(xl),ya(xl)) 



3 4 5 6 7 


9 10 11 


4. Total Ship Volume 


V tot := offt(xl) -Tidxl 


V tot = 16.602ft 


V — V 
V enva v tot 


^enva PsW'^to 


A enva = 1062.553b 


5. Tail Cone angle (measured from the axis of rotation to to the tangent at the stern). Greater than 18 degrees 
probably considered a full stern. 


= 15.814deg 


i + If ° 

2 4 


6. Total Prismatic Coefficient 


f D Y 
n> — L 

V 2 J 


C p = 0.657 
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7. Forward Prismatic and Wetted Surface Area Coefficients: 

Cw Sf = 0.8189 


Cwsa = 0.7333 


K1 := 6 - 2.4Cp f - 3.6Cp a K1 = 2.056 

K2 := 6 - 2.4C wsf - 3.60^ K2 = 1.395 

WS := 7t*D 2 -(LOD - K2) WS = 44.309ft 2 

10. Envelope Volume Balance. 

Outboard volumes are not included in the hull sizing. 

•s 3 Venva *“ Ysnvr 

V cnvr = 8.109ft 3 Venva = 16.602ft Err v :=--- 

Venvr 

Ensure that available volume exceeds required volume. A +/- 1% error bound is 
preferred, but most AUVs will require excess volume to achieve required buoyancy: 

If Err v < 0, then available volume is too small, so increase envelope volume. 

If Err v > 0, then available volume is too large, so decrease envelope volume unless 
restricted by weight. 
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IV. WEIGHT AND BUOYANCY 

A. Weight Estimation 


NOTE: This section not important if 
size of vehicle is known. The powering calcs 
are based on size, not weight. Cost is determined 
primarily from payload components (?). 


1. Lightship Weight (excluding fixed ballast) 


Traditional SWBS Groups 
Hull Structure 
Propulsion Plant 
Electrical Plant 
Command and Control 
Auxiliary Systems 
Outfit and Furnishings 
Mission Payload 


AUV Components Group Number 
Structure, Mountings 1 

Motor, Propulsor, Shaft, Gears, Fins 2 

Batteries, Wiring, Junctions 3 

Controllers, Recorders 4 

Ballast Equip, Hydraulics 5 

n/a 6 

Sensors, Navigation, Comms, Computer 7 


Required envelope and submerged 


displacements (from above) 




Group 1 fraction of availableenvelope displacement: 
Group 2 weight fraction (from above): 

Group 3 weight fraction (from above): 

Group 4 fraction of submeraed displacement: 
Group 5 fraction of submeraed displacement: 
Group 6 fraction of submeraed displacement: 
Group 7 (from spreadsheet): 


W lfrac := 

.15 

W 2ftac := 

-l 

Yprop 

^3frac*~ 

Y battery 

^4frac*~ 

.01 

W 5ftac *= 

,02 

6frac*~ 

0 


W7estW senS ors + + ^eomms + ^computer 



ESTIMATED VALUES 

ACTUAL VALUES Enter if known 

W lest : = W 1 fi-ac ^enva 

W lest = 159.3831b 

W, := W lest 

^2est :== ^2frac ^MotorRating 

W 2est = 55.9261b 

W 2 := W 2est 

^3est ^3frac-^Installed 

W 3est = 232.70ab 

W 3 :=W 3est 

^4est "^4fracas 

5.1041b 

W 4 :=W 4est 

W 5 es t * = A g 

W 5est = 10.2071b 

W 5 :=W 5est 

^6est *“ ^6ftac^s 

W fet = 01b 

W 6 :=W6es. 


W 7est = 36.7691b 

W 7 := W 7est 


Lightship weight 
(excl fixed ballast): 


W A i := Wj + W 2 + W 3 + W 4 + W 5 + W 6 + W 7 

Check: 


V A1 - 500.0951b 
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2. Ballast Requirements 

Positive Buoyancy as fraction of submerged displacement: B frac := 0.01 



Variable ballast volume: 

Ballast tank volume (from above): 

V ballastjank = 0.663ft 


V vb : = 0.9* Vbaiiast tank 

V vb = 0.596ft 3 


w vb :=V vb -p sw 

W vb = 38.1731b 

Negative buoyancy check: 

®neg := Bpos " ^vb 

B neg =-33.071b 


R ~ B " Cg 

°frac neg*~ 

A s 

Bfrac_neg= 0.065 

Bnegjheck: 

= if(B frac neg > B frao "OK" ,"NOT OK") 

WMSKS 

Weight Summary 



W ls 

:=W A1 + W lead A a := W| s | 

y b = 505.271b 

W fl : 

:= W ls + W vb | 

y ; = 543.4431b 



Speed range of interest: V — 0, .1.. 15 lOknt ; 

Sections A through C present different methods of calculating the drag 
coefficient. User can select method in Section E. 

A. Drag Coefficient (Jackson Wetted Surface), C D _ WET1 

1. Resistance calculation parameters: 

Vknt 

Reynolds Number: R N (V) := L- 

v sw 

Wetted Surface (previously calculated): WS = 44.309ft 2 

For ships, this is typically .0004. CAPT 

Correlation Allowance: C a ;= .0004 Jackson's notes indicate that C a should be 

.0002 - .0015 for submarines. 


2. Frictional resistance coefficient: Cf(V) :=- 1 - 

(log(R N (V))-2) 2 


3. Residual drag coefficient: The following equation for (Cf +Cr)/Cf was developed by Hoemer using the fact 

that the after end of the submarine has a large effect on the form coefficient (See 
Reference 1) 



Cfrf= 1-37 

C r (V) ^CftfCfW-CKV) 


4. Appendage drag coefficient: 

Check against alternative methods: 

1. Rule of thumb for submarines is that the non-sail appendages 
have a A*Cd ("App" below) value equal to approximately L*D/1000. 

2. Percentage of total resistance coefficient w/out appendages. 


Estimate appendage area as a fraction of 
wetted surface area and use 0.006 for 
appendage drag coef. 


Compare to: 

1 . App := — App = 0.0184ft 2 

1000 

2- C afi (V) := WS.(Cf<V) + C r (V) + C a ) 

Capp I0 %(V) := 0.10C af /V) 
CapplO-ZedO) = 0.0190ft 2 


5. Total drag coefficient: 

C D WETl (V) := C a + Cf(V) + C,(V) + Capp-fapp 



f app :=0.05 C app := .006 

Capp-fapp-WS = 0.0133ft 2 


B. Drag Coefficient (Hoerner Wetted Surface Method), C d_wet 2 



C. Drag Coefficient (Hoerner Frontal Area Method), C DFRO nt 
Total drag coefficient (bare hull only): 

CD_BH_FRONT( V ):= C f( V )' + 4 ' 5 + 21 ^C D _B H _ FR0 NT^^-j = 0 063 

D. Resistance 

1. Jackson Wetted Surface Method 

R x _weti (V) : = O.Spsw-WS'^wETiW^^^) 2 r t_weti 

2. Hoerner Wetted Surface Method (with Jackson method for appendage drag) 

Bare hull: 

r bh_wet 2(V) •= O.Sp sw -WS.C D _ BH _ WET2 (V)-(V-knt) 2 r bh_wet2 

Appendage: 

R app (V) := 0.5 p sw • C app -f app -WS ■ (V-knt) 2 ^{^f) = ° 551bf 

Total: 

r t_wet2 (V) := Rbh_wet2(Y) + RappOO R T_WET2 

3. Hoerner Frontal Area Surface Method (with Jackson method for appendage drag) 

Bare hull: 

71-D 2 2 

R BH_FRONt( V ) :=0-5 psW-^J— C D_BH_FRONT(y)-( Vknt ) RbH.FRONT 

Appendage: 

r app(^0 O.S P swCapp4ppWS.(V-knt) 

Total: 

r t_front(V) := r bh_front(^0 + r app(^0 r t_front 
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E. Powering Requirements 


Propulsive Coefficient: 
Motor efficiency: 


PC:= 0.85 

n motorJV * = 0.85 V eff 1 Oknt 
0 motor( V) : = r| m otor_V * (v* knt- V e ff 


Enter efficiency and corresponding speed 


Accounts for motor inefficiency at 
lower speeds. 


Resistance calc method: 


R t (V) := R t _weti (V) 


Enter desired method from previous section. 


Brake power (includes estimated PC and motor efficiency): 


BP(V) := 


R T (V)-Vknt 


550 


ft-lbf 


sec-hp ) 




3tor(V) 


VI :=4,6.. 10 


BP(V1) = 


0.254 

0.607 

1.127 

1.823 


kW 


F. Powering Results v_plot := 1,1.1.. 12 


| BP(vjlot) 


1 

m 


Speed-Power Curve 
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G. Maximum Speed (Submerged) 


a := 10 (initial estimate for root finder) 

^MotorRating = 2237.05 lwatt 

V max •“ rOOt(BP(a) - PMotorRating > a )*knt V max - 10.995knt ^search = 

Re-select motor size to achieve maximum V transit = lOknt 

required speed (usually Vsearch or Vtransit). 

H. Optimum Speed (Submerged) 

Optimum transit speed is that which uses one half the power of the hotel load: P transit = 1/2 * P hote , 
BPoptimum := 0.5P Ho telReq BP optimum = 107.175watt 

Following formula determines the speed at which the desired (i.e. ideal) transit power is achieved: 
b := 10 (initial estimate for root finder) 

V„p, imum := root(BP(a) - BP optimum , a>knt V optimum = 2.669knt For information only 


I. Energy Consumption and Endurance Calcs 
Endurance as a function of speed: 


Endurance (V) := 


installed 


BP(V) -I- P Ho telReq r~7\ 


VI = 


4 

f 

20.266 

6 

8 

-tS 

10 

1 4.663 



Endurancc(V) 

hr 
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Endurance based on mission profile: 


System endurance requirement: 

Time margin (incorporates adjustment from System Model to set all vehicle endurances equal): 


^margin •“ * cndurancc_rcq'“ v * transit + * search * excursion * prosccutej 


Energy consumption: 


p T 

transit •“ Dr l ^ 1 ‘transit 

EW=1-094kW.hr 


)' Tstimh 

E scarch =2.313kW-hr 


c 

Excursion •“ Dr l ^ 1 ‘excursion 

Excursion = 0.081kW-hr 

Assumes 1/2 Vsearch 
during excursions 

r n/ Vprosccutc 1 T 

‘-prosecute •” Dr l 1 1 prosecute 

prosecute = OkW-hr 

Assumes Vsearch during 
prosecutions 


Emargin= l-68kW.hr 

Assumes margin time 
spent at Vsearch 


Epropuisionjotal : = ^transit + ^search + ^excursion + ^prosecute + ^margin Efropulsionjotal = 5 . 168 kW-hr 
^Mission := Epropulsion total + EjjotelRcq 13 ^ 

Compare to: = 5.98kW-hr 


^Surplus ^Installed ^Miss 



L =. 10 5ft 
D - 21m 
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Appendix C 


Effectiveness Model 


MCM EFFECTIVENESS MODEL 


Model Description 

Include place for description of mission 


INPUTS 


Directions: 

IMPORTANT: Output files are written at the end of this file. If a new file is being created using a file for another 
system, be sure to change the output file names FIRST so as to avoid writing over the output for the other file. 

1. Insert links for System Model file and each AUV Design Module file (one for each vehicle type): delete 
old link first and then re-insert reference link (lnsert\Reference\... use relative link option). 

2. For each vehicle link, make sure the L & D lines are inserted and the correct subscripts are used. 

3 . When any changes are made to other files, these links must be updated by clicking once on the link and 
pressing F9. Do this for each link. (Be sure link files are saved first.) 


System Model Link: 

0 Reference:C:\My Documents\MIT\Thesis\Modeling\Ma$ter\System Model - Master.mcd(R) 
n V ch_totai '•= iff numtype > l,^Tnumveh ,numveh 



Vehicle Links (one for each type): |ppype|S|f| 

0 Reference:C:\My Documents\MmThesis\Modeling\Master\AUV Design Module - Master.mcd(R) 


LL t :=L LL, = 10.5ft 


DD, =21 in 


0 Reference:CAMy Documents\MIT\Thesis\Modeling/Case One\S2 AUV2.mcd(R) 
LLj:=L LLj = 8ft DDj := D Dp 2 = 12in 

Add additional links for each AUV type 
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MOE-MOP HIERARCHY Blue = MOE Purple = Sub-MOE Black = MOP 


Mission Time 

Effective Area Coverage Rate 

Multiple system parameters (modeled) 

Mission 

Accomplishment 

Search Level 
(through identification) 

Localization Accuracy 

Clearance Level 

Multiple system parameters (modeled) 

Navigation accuracy (modeled) 

Multiple system parameters (modeled) 

Autonomy 

Lift Support 

Host Support 

System Footprint (modeled) 

Host Platform Requirement(utility fen) 

Communication 

Reporting Frequency 

Data Type 

Reporting Frequency (utility fen) 

Data Type (utility fen) 

Covertness 

Deployment Phase 

Mission Phase 

Recovery Phase 

Platform Type (utility fen) 

Platform Type and Location (utility fen) 

Platform Type (utility fen) 
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MOE WEIGHTS 


This method for establishing the MOE weights is based on an Analytical Hierarchy Process technique 
sometimes called the "pairwise comparison matrix method". Here, only the upper-level MOE weights are 
derived using the matrix method; the sub-MOE are assigned directly because there are no more than 
three in any group to compare. To obtain valid weights, a formal survey process should be undertaken to 
extract the warfighter's preferences. Each pair combination [n(n-1 )/2, where n is the number of MOE] 
should be included in the assessment. 

A simplified approach taken for this thesis is shown here. The number pairwise comparisons is kept to 
the minimum [n-1], and all values are assigned by the author. 

Instructions: 

1. Place MOE in order from most important to least important. 

2. Re-order and update indices. 

3. Enter comparison values for the four F^i 

MOE Order 


1 Time 

Set indices: 

Time 

tm := 1 

2 Accomplishment 


Mission Accomplishment 

ma := 2 

3 Communication 


Communication 

co := 3 

4 Autonomy 


Autonomy 

au := 4 

5 Covertness 


Covertness 

cv := 5 
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MOE Pairwise Comparison Matrix and Eigenvalue Problem 


1 

RI 12 

RIl3 

ri , 4 

RI, 5 ^ 











r 1 1.5 

4 

6 

8 ^ 

RIl 2 _1 

1 

ri 23 

RI 2 4 

ri 25 


0.667 1 

2.667 

4 

5.333 


RI^" 1 

1 

ri 34 

RI 35 

MOE = 

0.25 0.375 

1 

1.5 

2 

_ 1 

— 1 

_ i 




0.167 0.25 

0.667 

1 

1.333 

RIl4 

RI24 

ri 34 

i 

RI 45 












^0.125 0.188 

0.5 

0.75 

1 J 

Wis " 1 

Rh5~' 

Rhs 1 

Rl45 _1 

1 J 

1 





(O') 


eigenvals(MOE) = 


5 

0 

0 




max_ev:= ma>(eigenvals (MOE)) max_ev = 5 


Inconsistency ratio 
(must be less than 0.01) 


Re(max_ev) - rows(eigenvals(MOE)) 
rows(eigenvals (MOE)) 


IR = 0 


Weights obtained from eigenvector associated with maximum eigenvalue: 


eigenvec (MOE, Re(max_ev)) = 


^ 0 . 803 ^ 

0.535 

0.201 

0.134 


V 0.1 ) 


sum ev := eigenvec (MOE, Re(max_ev)) 


sum ev = 1.774 


Normalized MOE weights: 


MOE_wt:= 


eigenvec (MOE, Re(max_ev)) 
sum ev 
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TIME MOE 


MOE Description 

The Time MOE represents the time required for the AUV system to accomplish the assigned mission 
objectives. 


Sub-MOE Description(s) 

Effective Area Coverage Rate Ratio of the total search area to the total amount of time required 

to complete the mission objective(s), from AUV system 
deployment to recovery. Includes time spent in the search area 
plus transit time to/from the search area . 

Alternate: 

Total Mission Time The total amount of time from AUV system deployment to 

recovery. Includes time spent in the search area plus transit time 
to/from the search. 


Weights 

Time MOE 


Area Coverage Rate 



Contributing System Parameters (MOP) 


Number of tracks 

n 

2 

Track spacing 

D track =571.42M 

Runs per track 

J= 1 

Track length 

Usearcharca = 311111 

Search speed 

Vscarch- 10. 125ft sec 

Transit speed 

^transit “ lOknt 


Total track run distance 

dtrack_runs — 21 nm 

Total turn distance 

d turos = 1.862nm 

Distance into search area 

<W«s= lnm 

Distance out of search area 

degress = 5 nm 

Distance to recharge point 

^recharge 

Number of recharges 

^recharge 

Recharge time 

T 

1 recharge 


Contributing Mission Parameters 

Search area dimensions Lsearcharea= 3 nm 

W searchare a=4x 10? yd 


Estimated number of mines NM = 25 
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Relationships 


MOE Determination Method : MODELING 


^mission = T search + T^^ + T serv j ce + T excurs j on = T en( j U rancc_req 
Lsearcharea W se archarea 

ACR^ffS 


Results 

^mission := T en{ j ura nce_req 

Lsearcharea W searcharea 
ACReff:=-- 



MISSION ACCOMPLISHMENT MOE 

MOE Description 

The Mission Accomplishment MOE represents the estimated condition of the searched/cleared area 
after the mission is completed. This MOE reveals the extent to which any specified mission objectives 
were achieved or surpassed. 


Sub-MOE Description(s) 


Search Level (through identification) FOR NON-CLEARANCE MISSIONS ONLY. Cumulative joint 

probability of detecting, classifying, and correctly identifying mines 
within the specified search area. Also known as "Percent Search". 

Localization Accuracy FOR NON-CLEARANCE MISSIONS ONLY. Represents the 

distance error between the reported mine positions and the actual 
mine positions. Also called "contact position error". For this 
model, the contact position error is taken as a function of the 
system navigation error (%DT). [Note: if determined by 
post-analysis or simulation, localization error could be given as 
Distance Root Mean Squared (DRMS).] 

Clearance Level FOR CLEARANCE MISSIONS ONLY. Cumulative joint probability 

of detecting, classifying, identifying (optional), and neutralizing 
mines within the specified search area. Also known as "Percent 
Clearance". Note: Model is currently unable to handle clearance 
missions . 
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Weights 


Mission Accompiishment MOE Wt A cmp := MOE wt ma 


Search Level (through ID) 
Localization Accuracy 
Clearance Level 


Enter value: WtsL:=0-6 
Wt la := 1 - Wt SL 
Wt CL := if(wt SL = 0,1,0)* 



Contributing System Parameters (MOP) 
Number of tracks 
Runs per track 
Track spacing 

Standard deviation of track keeping 

Characteristic search width 


Characteristic probability of detection/classification 


Maximum acceptable position error 
System Navigation Error (%DT) 


N = 7 


J= 1 


T>tock= 571.429yd 


a = 


^15 30 0 0^ 
15 30 0 0 
^15 30 0 0 y 


ft 


A = 


^588 588 0 0^ 
0 0 0 0 
^ 0 0 0 0 > 


yd 


B = 


^0.876 0.9 0 0> 
0 0 0 0 
^ 0 0 0 Oj 


max_pos_error = 30yd 
%DT = 0.05 


Contributing Mission Parameters 


Target strength y = -30dB 

Bottom type BT = 4 


Water depth 


d avg = 400ft 


Disabled 
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Relationships 


MOE Determination Method : MODELING 


, x / _ M Y \ Note: Percent clearance just adds probability of 

^search = U _ ~ e ) neutralization 

p — (1 — • I ) p p {1 — p” ^ 

i A R 1 clear“ V 1 P/ r imm’ r nmm‘ c ' 

where m = 

l^track 



avg_pos_error = 0.5max_pos_error 


Results 

^search := ^search 

avg_pos_error := .5*max_pos_error 



AUTONOMY MOE 

MOE Description 

The Autonomy MOE represents the independence of the system from logistics support and/or oversight for 
guidance and tasking. It is expressed in terms of a normalized score on a scale of 0 to 1. 


Sub-MOE Description(s) 

Lift Support Amount of cargo space required for deployment/recovery of the system, 

given in terms of area (e.g. sqft) 

Host Support Level of service and/or command and control support required during a mission. 

This requirement is specified in terms of discrete host responsibility alternatives 
(e.g. dedicated platform, remote command and control, none, etc.) 


Weights 

Autonomy MOE 


Lift Support 


Host Support 
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Contributing System Parameters (MOP) 


Number of vehicle types 
Number of vehicles (each type) 

Vehicle(s) dimensions 

Reliability/redundancy 
Recharge method 

Host-system communication method 


numtype = 2 
numveh = (1 2) 


10.5^ 

f 21 1 

ft 

DD = 

V 8 ) 

V12/ 


reliability = "LOW" 

recharge = "NR" 

comm method = "RF-SAT" 


Relationships 

MOE Determination Method MODELING / UTILITY FUNCTION 


Lift Support = Total System Footprint 


numtype 

FP sys= ^ f s tow.-nU mveh i FP veh. 
i = 1 


where FP veh = [sqft] 

^ is stowage multiplier 


Host Support 


None required 1.0 

Command/control only (remote) 0.7 
In-theater/dedicated 0.0 


Results 

L := LL D := DD 


f 

F^sys •” 

V 


numtype 


> 1 


numtype 

•i 


i = l 


\ 

numveh j t * Lj• D } , numveh • L v • D l 

) 



Note: Footprint calculation does not 
include any system/vehicle stowage 
factors 


Score host 


0 if (reliabilitys "LOW" v commmethods "AM" v comm_method= "RF-LOS" v recharges "HOST") 
0.7 if comm methods "RF-SAT" 


1.0 otherwise 


Scorehost 0.7 
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COMMUNICATION MOE 

MOE Description 

The Communication MOE represents the system's capability to receive and/or transmit information from/to a 
host. It is expressed in terms of a normalized score on a scale of 0 to 1. 

Sub-MOE Description(s) 


Reporting Frequency 


Frequency of transmissions from system to host or vice 


Data Type 


Low: CAD/CAC, system position/status, contact 
positions, etc. Also, command and control-related 
information from host; 

High: Post-processed data intended for human 
interpretation (e.g sonar imagery or "snippets”) 


Weights 


Communication MOE 


Wt COMM MOE^o 


Reporting Frequency 


Enter value: 


Data Type 


Wt DT := 1 - Wt^ 




Contributing System Parameters 


Host-system communication method 


comm method = "RF-SAT" 


Reporting frequency 


reportfreq = "PRD" 


Relationships 


Data Type (Content) 

High Content 1.0 
Low Content 0.7 
None 0.0 


Reporting Frequency 

Continuous 1.0 

Periodic 0.5 

None 0.0 


Results 


e := 0 if comm_method = "NR" 

0.7 if comm_method = "AM" 
1.0 otherwise 


'®re P ort_freq' = 0 if reportjreq = "NR" 

0.7 if report freq = "PRD" 
1.0 otherwise 


{Score^jype — 1 


fScorwy^ 0.7 
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COVERTNESS MOE 


MOE Description 

The Covertness MOE represents the extent to which the system's presence and efforts are difficult to detect. 
It is expressed in terms of a normalized score on a scale of 0 to 1. 


Sub-MOE Description(s) 
Deployment Phase 


Mission Phase 


Recovery Phase 


Ability to avoid detection during deployment phase of 
operation. 

Ability to avoid detection during mission (search/clearance) 
phase of operation. 

Ability to avoid detection during recovery phase of operation. 


Weights 

Covertness MOE 


Wt cvrt *— MOEjvU 



Deployment Phase 
Mission Phase 
Recovery Phase 

Check sum: 


Enter value: 

Wt DP :=0.4 pi 

Mm3. 

Enter value: 

Wt MP := 0.25 pvi 

1fegg 

Enter value: 

WtRp :=0.35 jp 

BE 

Chk:=i£(\Vt 

DP + Wt MP + Wt Rp) = 1 

, "OK" , "Weights must sum to 1.0" ] 



Contributing System Parameters 

Clandestine delivery method cland_deliv = "AIR" 

Clandestine recovery method cland_recov = "SURF" 

Host requirement (from Autonomy MOE) 


Relationships 


Deployment Platform Type Recovery Platform Type Mission Phase Platform 

Type & Location 


None Reqd 

1.0 

None Reqd 

1.0 

None Reqd 1.0 

Sub 

0.9 

Sub 

0.9 

Satellite/air link 0.9 

Air 

0.3 

Air 

0.3 

Sub 0.6 

Surf 

0.0 

Surf 

0.0 

Surf 0.0 
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Results 


x := clanddeliv 
Score^epioy 


x= "AIR" 


(Scorejjepioy - 0.3 


y := cland_recoy = "SURF" 


2 := Scoreho 


z = 0.7 


0 if x= "SURF" Score recov := 

0 if y = "SURF" Score m j ssi0 n := 

1.0 

N 

11 

0.3 if x= "AIR" 

0.3 if.y = "AIR" 

0.9 

ifz^OAz^l 

0.9 if x= "SUB" 

0.9 if y = "SUB" 

otherwise 

1.0 otherwise 

1.0 otherwise 


0.6 if x= "SUB" 




0 otherwise 


r Score rccov —0 


WL' ’T' ' ' 

I;SCOrS triissioti “ ^ ^ 


Note: assumes sub will serve as mission 
host if sub is the delivery platform 
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SUMMARY 


MOE Values: 


, = 7.658hr 


2 

ACR € ff= 0.774— 
hr 


Psearch - 0.977 


avgpos error = 15 yd 
FP sys = 55.125ft 2 
Scorehost ~ 0.7 
Score r ep 0 rt_freq = 0.7 

Score datatype ” ^ 

Score deploy = 0.3 

Score recov 0 

Score mission = 0.9 


MOEResults := 


^mission 

hr 

ACR c ff 

2 , -1 

nm -hr 

Psearch 

avg_pos_error 


yd 

PPsys 



Scorehost 


Score report_fireq 
Score data_type 
Scoredeploy 
Score recov 
Score mission 


Output link 
not shown 


MOE Weights: 

WtfiME - 0.453 WtACR = 1 

WtACMP = 0.302 WtsL = 0.6 

WtLA = 0.4 

wt atmy = 0.075 Wt LR = 0.25 

WtHR = 0.75 

Wt CO MM = 0.113 Wt RF = 0.3 

Wt DT = 0.7 

WtcvRT = 0.057 Wt DP = 0.4 

Wt MP = 0.25 
Wt RP = 0.35 



Outpute link 
not shown 


Ouput link 
not shown 
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AUV MCM System OMOE Spreadsheet 


System name: SI - Single Vehicle, Multiple Sensor s 


RED = pre-defined weights 
Capability 


BLUE = calcs. 
MOP 


Threshold 


MAGENTA= Model Score 

MOP 

Goal Attained 


|Overall MOE~ 



0.217 0.217 


0.600 |Search Level 

1 0.94 

0.612 

1 

0.977 

0.302iMission Accomp | 0.400|Localization Accuracy 

~ | 50 

5 

15 

0.678 

O.OOOjClearance Level 

0.778 

=Z1 i 

0 

0 

1.000 Check = 1.000 

1.000 





1 

0.250|Lift Support i 500 

50 

18.38 

0.432 

0.0751Autonomy 

] 1.000 





0.250 

0.750|Host Support/Oversight | Dedicated 

0.000 

None Reqd 

0.00 



1.000 Check = 1.000 





0.300|Reporting Frequency 

ZZJ 

None 

None 

Continuous 

High 

0.70 

1.00 

0.113|Communication j 

0.910 

0.7001Data Type 

1.000 Check = 1.000 

0.700 

-1 

1.000 


0.400|Deploy Phase 

_ 1 

Surf 

None Reqd 

0.30 



0.300 




0.0571 Covertness | 

0.250[Recovery Phase 

1 

Surf 

None Reqd 

0.00 

0.120 


0.000 





0.350|Mission Phase 

-1 

Surf (ded) 

None Reqd 

0.00 


0.000 

1.000 Check = 1.000 


1.000 Check = 1.000 
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Appendix D 


AUV Sub-system Databases 

The databases shown in this Appendix are accessed through the Excel link in the System 
Model. In general, they contain weight, volume, and electric power characteristics for a catalog 
of AUV sub-systems. In the interface sheet of the Excel link, the user configures each AUV 
by selecting the proper designation from among the options. The corresponding information 
is then extracted from the databases using lookup features and passed to the System Model 
(i.e. for the AUV Design Module). The items and numeric values in these databases should be 
observed with caution, as they were derived from various sources and have not been validated. 
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SONARS DATABASE 


Source: MCM Future Systems Study Workbook 

Comments: ALS/SAS data for wide beam only (meant for deeper water, i.e. 200+ ft); wt/vd/pwr given for arrays and electronics, but not signal processing 


Sonar Type 

Sensor Desig 

Min Vehicle Diameter 

Wt 

Vol 

Power 



in 

lbs 

cu in 

w 

Ahead Looking Sonars (ALS) 

ALS-4 

4.875 

9.1 

396 

87.3 

ALS-7 

7.5 

10.6 

475 

91.6 


ALS-12 

12.75 

14.2 

617 

128.6 


ALS-21 

21 

20.3 

924 

139.4 


ALS-36 

36 

37.3 

1726 

142.7 


ALS-54 

54 

68.2 

3160 

174.2 

Sythetic aperature sonars (SAS) 

SAS-4 

4.875 

2.9 

146 

18.9 


SAS-7 

7.5 

4.3 

284 

26.6 


SAS-12 

12.75 

9.3 

954 

48 


SAS-21 

21 

19.6 

2633 

76.1 


SAS-36 

36 

53.3 

11296 

81.9 


SAS-54 

54 

127.3 

33572 

82.1 

Side-scan sonars (SS) 

SS-12 

12 

7.0 

716 

36.0 

SS-21 

21 

14.7 

1975 

57.1 

Note: must change lookup formulas in SysDefn sheet if expanded past current point 





ID SENSORS DATABASE 








Source: MCM Future System WG 








Comments: Traditional sensors listed here; see WG paper for more advanced concepts 







ID Sensor Type 

Sensor Desig 

Min Vehicle Diameter 

Wt 

Vol 

Power 

Diameter 

Length 



in 

lbs 

cu in 

w 

in 

in 

Deep Sea SS-126C Video/Lighting 

ID-LOW 

n/a 

0.20 

2.88 

5 

1.26 

2.31 

Benthos DSC 4000 Dig Still Camera 

ID-MED 

n/a 

5.00 

143.14 

12 

4.50 

9.00 

Benthos DSC 5010 Dig Still Camera 

ID-HIGH 

n/a 

7.25 

143.14 

45 

4.50 

9.00 


Note; can expand to cell 20 without changing current lookup formulas in SysDefn sheet 


no 




NAVIGATION PACKAGE DEFINITION 


Instructions for adding or modifying navigation packages: 

1. Make entries in yellow section only. Gray sections are updated automatically. 

2. To add a component to a nav package, highlight the second row of a package (inside the framed box only), and insert rows usini 
the "shift cells down" option. Type the new component designation number in the 4th column. 

3. To create an entirely new nav package, either replace an existing one or insert cells as described in item 2 (except highlight the 
white between the frames instead). 


Nav Suite 


Accuracy 

%DT 


Vehicle 

Type(s) 


Component Weight 

Designations Component Names (lbs) 


Volume 
(cu in) 


Power 

(W) 



png laser gyro 
Pendulous 




1.0 16.5 

0.8 4.4 0.2 

iir . 


IINS-DVS 


Rsvd for future 


Guide 

Hunter 



14 
18 
2 


png laser gyro, ^ . 1.0 J 

Pendulous ■' ■ ' 0.8 % 

:dvs 8.o . 


16.5 1.6 

4.4 0.2 

118.8 % 20.0 




DR-DVS-GPS 


Rsvd for future 


Guide 


5 

2 

27 


Gyrocompass 

DVS 

Military Rcvr . 


?% 


8.0 

8:0 

0.2 




198.9 
118.8 


4.0 

20.6 

%1;2 


mmmmmm , ; i6.2 * 


INS-ABR 


Rsvd for future 


Hunter 


14 

18 

24 


^Pendulous Jlfi 
Super-directional 


- 

' 0.8 

ltf^.6 




^Gyrocompass 
DVS; 
Super^directlonal 


ao 

• >4.6'%- 


. 16.5 

402.1 


198.9 

118.8 

402.1 



INS-DVS-GPS 


Rsvd for future 


Guide 


Ring laser gyro 

Pendulous 

DVS 

Military Rcvr 





lNS-Dvs-GPS Subtotal ^ i1 wMMMm mmm 


NAVIGATION COMPONENTS DATABASE 

Source. MCM Future Sys»«n» Suxfy Wotw* 
Comments: 


Navigation Technique 
Dead Reckoning 


Inertial Navigation 


Acoustic Baseline 
Radio Navigation 


8y*tamSCofnpon*nt 

Typ. 

V«ocrty Senwn 


Hearing Seraor* 


AKitrti Senear 
Dec**' Saerr 
Rr>i. ^ S aw 

Stxrri Speed Saury 

Gy-aecop# 


IMU 


Long Basel ne (LBL) 
Ultra-Short BL (USBL) 
GPS 


GLONASS 


1 Item 

Model 

Length (In) 

Length Dim 

Width (In) 

Width Dim 

Height (in) 

Volume(cu In) 

1 EM LOG 

AGILOG 

8.0 

dia 

8.0 

dia 

11.4 

573.0 

2 DVS 

microDVL 

5.5 

dia 

5.5 

dia 

5.0 

118.8 

3 Correlation 

ACCP 

17.3 

- 

17.3 

- 

8.7 

2603.8 

4 Compass 

Cl 00 

4.5 

- 

1.8 

- 

1.1 

8.9 

5 Gyrocompass 

GyroTrac 

7.8 

- 

5.0 

- 

5.1 

198.9 

6 North-finding gyro 

MintFOG 

11.8 

dia 

11.8 

dia 

16.0 

1749.7 

7 Altimeter 

PSA-900 

4.0 

dia 

4.0 

dia 

11.5 

144.5 

8 Depth Sounder 

TJE 

1.5 

dia 

1.5 

dia 

2.0 

3.5 

9 Clinometer 

AccuStar 

2.5 

dia 

2.5 

dia 

1.2 

5.9 

10 Inclinometer 

TCM2 

2.5 

- 

2.0 

- 

1.3 

6.3 

11 CTD 

MicroSVP 

2.9 

dia 

2.9 

dia 

13.8 

93.7 

12 Velocimeter 

Smart Sensor 

1.8 

dia 

1.8 

dia 

12.4 

31.6 

13 Mechanical 

RG78 

3.7 

dia 

2.0 

dia 

1.8 

19.0 

14 Ring laser gyro 

GG1320 

3.5 

dia 

3.5 

dia 

1.8 

16.5 

15 Fiberoptic 

Ecore 100 

4.3 

- 

3.5 

- 

1.6 

24.1 

16 MEMS 

Gyrochip QRS11 

1.5 

dia 

1.5 

dia 

0.6 

1.1 

17 Mass-spring 

LA67 

1.0 

dia 

1.0 

dia 

2.5 

2.0 

18 Pendulous 

LSBC 

2.6 

- 

1.2 

-- 

1.4 

4.4 

19 MEMS 

CXL02F3 

2.0 

- 

1.2 

- 

0.9 

2.1 

20 IMU 1 

TGAC-RC 

7.9 

- 

8.7 

- 

13.8 

9392 

21 IMU 2 

LN-200 

3.5 

dia 

3.5 

dia 

3.4 

322 

22 IMU 3 

Motion PAK 

3.0 

- 

3.0 

- 

3.6 

32.4 

23 Omni-directional 

Trackpoint II 

2.8 

dia 

2.8 

dia 

24.0 

142.5 

24 Super-directional 

Type 7978 

72 

dia 

7.2 

dia 

39.5 

1608.2 

25 Civilian Rcvr 

Sensor II 

4.2 

— 

2.3 

- 

0.6 

5.7 

26 DGPS Rcvr 

DSM212L 

7.7 

- 

5.7 

- 

2.0 

87.8 

27 Military Rcvr 

12 MPE-1 

42 

- 

2.7 

- 

0.6 

6.8 

28 Receiver 

GG24 

6.5 

- 

4.0 

- 

0.6 

15.6 
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COMMUNICATIONS DATABASE 


Source: None 

Comments: Rough guesses only -- need to build database 



Desig 

Wt 

Vo 1 

Power 



ibs 

cu in 

w 

Acoustic Modems 

AM 

1.5 

37.03 

9 

Laser Modems 

LM 

Future 

Future 

Future 

RF Units 

RF 

1 

24.69 

3 

Combinations 

AM + RF 

2.5 

61.71 

12.00 


COMPUTER/PROCESSOR DATABASE 


Source: MCM Future System WG 

Comments: Traditional sensors listed here; see WG paper for more advanced concepts 


Computer/Processor Type 

Desig 

Wt 

Vol 

Power 



Ibs 

cu in 

w 

Basic Guidance, & Control & Veh Housekeeping 

GC 

2 

75.00 

15 

Basic G&C + Kalman Filter 

GC+K 

3 

100.00 

20 

Basic G&C + Kalman Filter + Sonar Post-Processor 

GC+K+S 

4 

300.00 

40 
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